[MPlayer-dev-eng] [patch] prefer ALSA over OSS
Rich Felker
dalias at aerifal.cx
Thu May 3 20:14:29 CEST 2007
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
More information about the MPlayer-dev-eng
mailing list