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

[Uoti Urpala]

On Fri, 2007-05-04 at 12:55 -0400, Rich Felker wrote:
> 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.

Also because ALSA is the default audio API that "must work" on Linux
distributions. If there are problems with OSS emulation that might be a
problem for some programs; if ALSA doesn't work in a common
configuration that's a critical bug which needs to be fixed immediately.
We want to use the platform's standard interface when possible.

Point 2 could also be stated more strongly: people expect the standard
ALSA features to continue working as usual in MPlayer too.

> 3. Ideological wish for OSS API to die, and therefore a wish for

I think "ideological" better describes your claims than anything the
"pro-ALSA side" have said.

> 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.

The normal ALSA functionality is something users can expect by default,
not something they should need to separately configure. There is a
reason to prefer ALSA: it's the standard Linux sound API, and the one
that users most likely have working.

> 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

Maybe you shouldn't have started it then...


I already wrote about the practical features of the AOs in an earlier
mail, but there was no further discussion about them. Here are the main
points again:
- an ALSA hardware device supports pause and has accurate snd_pcm_delay,
but lacks some ALSA functionality such as mixing support
- the default ALSA device with mixing has no pause and snd_pcm_delay
seems less accurate (jumps around a few dozen ms; not bad as a desync
amount, but if video frames are timed directly based on audio position
then having their timing vary by that amount could matter)
- OSS emulation is strictly inferior compared to an ALSA hardware
device. It has no pause, but delay value is still accurate unlike the
default ALSA device.

Because of the delay measurement issue I'm not sure about switching the
default to ALSA at the moment. If the ao used a hardware device by
default then it would be an improvement over OSS in every way; but I'm
not sure whether such a default would be good either since the users
might expect it to have features only present in the default device.

I can understand not supporting pause with mixing (if the samples have
already been combined with other streams you can't pause one stream
without pausing the others too). However I don't see any fundamental
reason why snd_pcm_delay would have to be inaccurate with mixing.
Samplerate conversion could have a slight effect but it shouldn't be
much. Can anyone familiar with ALSA internals tell about the delay
measurement and whether it could be improved?