> 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
Thanks! This explanation did the trick for me. Now, I feel enlightened. ;-) Ico
