[MPlayer-dev-eng] Practical outcomes of the ALSA thread

Rich Felker dalias at aerifal.cx
Fri May 4 18:55:06 CEST 2007


Let's keep flames in the other thread if we can. Here I want to
discuss the original question, MPlayer's default/preference.

In summary, the pro-ALSA side seems to have the following reasons for
wanting ALSA to be default:

1. Desire for support for audio hardware that does not presently work
with the OSS emulation, either due to bugs in the kernel or in MPlayer
(it's disputed where the bug is).

2. Desire to use ALSA-specific features (soft mixing? etc.?) with
MPlayer.

3. Ideological wish for OSS API to die, and therefore a wish for
applications using OSS API to favor ALSA and deprecate their OSS
support.

On the other hand, the anti-ALSA side seems to have these reasons:

1. Lack of trust for the quality and reliability of ALSA due to past
record of bugs in both ALSA itself and the MPlayer AO module.

2. Difficulty and uncertainty of using the ALSA API correctly due to
lack of documentation and stability.

3. Belief that OSS API is technically better, and the ideological wish
for applications (specifically MPlayer) to take a stand and push for
the better API by maintaining it as the default.


Now, what to do? Obviously you're going to expect me to say stick with
OSS as the default, and you'll be right, but here's at least a
hopefully-reasonable argument why...

Pro-ALSA argument #1 seems to be a non-issue, because MPlayer should
just fallback to ALSA if it cannot open and configure the OSS device.
However Vladimir has reported a case where MPlayer "gets stuck" doing
this. We should simply track down and fix this bug and then hopefully
he'll be happy.

Pro-ALSA argument #2 has some validity, but by the same token, so
would a pro-ESD or pro-aRtS argument. IMO users who want this
functionality can configure it. There's no reason to prefer one
high-level sound API (ALSA) over another.

Pro-ALSA argument #3 and anti-ALSA argument #3 have both been
discussed to death in the flame thread.

Anti-ALSA argument #1 still stands unless we can be sure there are not
regressions. I for one know that ALSA output on my new laptop is buggy
but the OSS emulation works fine. Just like Vladimir can't be
bothered to help us fix bugs in OSS, I can't be bothered to spend my
time tracking down this bug in ALSA because I don't like ALSA and
don't have any desire to use it.

Anti-ALSA argument #2 is basically related to #3, I think...

Hopefully my analysis here seems reasonable. If you'd like to discuss,
feel free, but I've gotten pretty sick of this flamewar and intend to
drop it soon (or now perhaps) so keep the flames in the other thread.

Rich



More information about the MPlayer-dev-eng mailing list