[MPlayer-dev-eng] [patch] prefer ALSA over OSS

[Rich Felker]

On Thu, May 03, 2007 at 07:11:21PM +0200, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXV, Ivan Kalvachev a écrit :
> > ALSA project haven't publically documented the API they use to
> > communicate with the ALSA kernel modules. So it is not standard and
> > ALSA could decide to change it at any moment.
> 
> Well, that is the whole point. They do not want to make it standard because
> they want the users to go through the library only. There are two reasons to
> that:

Yes, i.e. they're actively malicious against developers and users.

> - For one, they think that
> 
>   snd_pcm_hw_params_set_rate(pcm, params, 48000, 0);
> 
>   is a cleaner way to talk than
> 
>   int rate = 48000;
>   ioctl(dsp, SNDCTL_DSP_SPEED, 48000);

It's not cleaner, it's much worse. One way in which it's worse is
fundamental; you cannot pass/inherit ALSA device contexts across
exec() or via sending file descriptors over unix sockets or fifos;
doing this with OSS is trivial because the device model fits naturally
with unix device/file/permission semantics.

> - For two, having an userland library allows to do some things that it would
>   be very bad taste to go in kernelspace, like parsing a configuration file,
>   loading plugins or altering the audio stream.

These things don't belong in the hardware abstraction at all. They
belong in sound servers, filter APIs, etc. -- things which some users
may OPTIONALLY choose to use, while others who do not need them
ignore.

> I have programmed a little both with OSS and ALSA, and I find that neither
> is really more agreeable than the other. And there is this huge point for
> ALSA: I do not have to worry whether the device will support the particular
> sample rate / channel count / sample format I need to use: the library will
> convert it on the fly if needed.

This is not a plus. It means your application will behave erratically
and have horrible performance or low quality in unpredictable ways.

Rich