Re: Is it time for remove (crap) ALSA from kernel tree ?

Tomasz Kłoczko
2007-06-25T09:52:16Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3856 bytes --]

On Sun, 24 Jun 2007, Alan Cox wrote:

>> Sory Alan but I don't want philosophical/historical discuss.
>> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API

How better and where better ?
Please be more verbose :>

> - is more flexible

Yes .. if you have API with thin abstracttion (like ALSA has) theoreticaly
you can do more but also by lack of some abstraction normal/usual things
must be implemented in harder way. This was theory .. pracice is completly
diffrent because some applications still provides better soud support
(without interruption) when uses OSS emulation placed on top ALSA layer
than compiled for direct use ALSA API.

Sound it in not rocket science. In 99.9% cases you need well abstracted
API which ALSA doe not provide and this is real cause why so poor sound
support in Linux applications is. Thin ALSA abstraction is main cause of
avalaibability "tons" of additional soud user space APIs.
"Nice" plot with current situation you can see on:
http://blogs.adobe.com/penguin.swf/linuxaudio.png

On above blog with this picture you can find more arguments against ALSA.
Your "more flexible" API in this case mean "ALSA provides only
atomic/elentar API". Result: look on for example GNOME mixer (or alsa-util
term based mixer). After each change soud card type in your computer you
will see changes in triggers set. More .. your "more flexible" API does
not provides usualy expected soud adjustmets parameters like volume level,
central balance .. but instead provides PCM level. Try go on street
(sometimes) and ask some PC users or someone who have at home audio
devices like TV/radio/whatever and ask them "what is it f* PCM ?".
Yes .. ALSA provides "more flexible API" if you want "fly using glider
have only raw pieces of wood" .. not if you want just fly and nothing
more.

On http://blogs.adobe.com/penguin.swf/ you can see also calling for better
abstracted API.

> - provides OSS as emulation

OSS provides ALSA emulation too.
Sorry but for me there is no technical argument.

> - supports more hardware

Please .. talk obout/back to ALSA/OSS API/KAPI compare.

> I used to maintain the kernel OSS code (the fork when Hannu and friends
> took their project non-free). I did the work to make the sound layer
> modular when the vendors realises that the open one needed to be modular
> and that since that was the main play of the non-free one that Hannu
> wasn't going to be doing it. From a technical perspective ALSA is the
> better design especially for flexible devices.

Look at Hannu blog and grab more arguments against ALSA:
http://www.4front-tech.com/hannublog/

To above I can only add again my argumet (which you saw more than year ago
and still is without response): ALSA does not provide secure way for manage
sound device on mixing level.

> At the desktop level these days it doesn't really matter much, the
> desktops use their own sound servers which sit on top of OSS, ALSA and
> other sound systems.

So .. why ALSA provides so thin API if in most cases applications
want only open soud device and/or in some more sohisticated case soud
device in stere, 4+1, 5+1 or so mode .. why provide API which not
provides this expected functionalities in easy way ?
Bad/poor design or API planning or not well educated programmers or maybe
ALSA still is developed by "belivers" (not enginers) who don't beleve in
"soft mixing in kernel space isn't possible/secure" (even if it is
provided in OSS) ?

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*