Subject: Re: [linux-audio-dev] ALSA vs OSS/free
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Mar 10 2002 - 04:57:18 EET
>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
This archive was generated by hypermail 2b28 : Sun Mar 10 2002 - 04:47:12 EET