User:PaulDavis

From the ALSA wiki

(see http://www.op.net/~pbd/ for information about Paul Davis.)

Re: [linux-audio-dev] ALSA vs OSS/free

From: Paul Davis <pbd@Op.Net>

To: linux-audio-dev@music.columbia.edu

Date: Sat, 09 Mar 2002 21:57:18 -0500

>Since we are talking about this [non]issue, again, I just realized that there is one thing I am still not able to comprehend completely, so I would greatly appreciate any thoughts on this one. > >It is no rocket science to figure out that Alsa is the way to go, and I am all for it. But one thing I do not comprehend is why is the user-space driver better than the kernel space one?

ALSA isn't a user space driver.

Its a kernel space driver that comes with a user space library. The library has several purposes:

1. hide hardware specific details that are represented at the raw device level (i.e. via /dev/snd/...)
2. encapsulate common operations (e.g. rate, format, channel conversions) done by applications
3. provide high-level functionality, such as device "sharing", channel mapping, and so forth
4. provide named identifiers that describe not just the hardware associated with a device, but various software characteristics. for instance, the hardware might have 3 different PCM outputs (e.g. analog, ADAT, S/PDIF) - the name might refer to just one of them. this avoids every ALSA program from developing its own way of having the user specify which attributes of a hardware device, or which configuration, they wish to use. when aplay is used with "-D trident" and jack is used with "-d trident", the name "trident" refers to a centralized resource described in ~/.asoundrc (and/or the system-wide equivalent)

You can use ALSA without using alsa-lib. If you do this, you lose all the functionality of alsa-lib, and are presented with a set of device drivers that mirror whatever the underlying hardware can (or cannot) do. You will not be able to deliver non-interleaved samples to consumer hardware. You will not be able to use 24 bit samples on 16 bit hardware. You will not be able to split a multichannel device into several "fake" devices. And so on. Very few people want to use this kind of interface, at least not by default. ALSA will allow you to be limited in this way if you wish, but it doesn't force it upon you.

The reasons for moving so much functionality into user space (rather than putting it all in the kernel, so that /dev/snd/foo does "everything" all by itself) are:

1. allows use of floating point operations (not allowed in the kernel)
2. code runs with regular user scheduling, not kernel space scheduling (this affects a few parts of how the scheduler sees things)
3. avoids putting often tricky and buggy code in the kernel, where debugging it is much more complex.
4. allows upgrading and bugfixes without changing kernel versions (for people not using modular drivers)
5. the kernel is supposed to provide mechanism for things that require priviledge to do, not policy and not mechanism for things that can be done from user space. 95% at least of the code in alsa-lib is about simple mechanisms that are provided by the code's functionality (no priviledge needed).

--p