Subject: RE: [linux-audio-dev] ALSA vs OSS/free
From: Ivica Bukvic (ico_AT_fuse.net)
Date: Sun Mar 10 2002 - 05:33:53 EET
> 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
This archive was generated by hypermail 2b28 : Sun Mar 10 2002 - 05:25:06 EET