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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jun 2007 11:51:59 +0200 (CEST)
From:	Tomasz Kłoczko <kloczek@...y.mif.pg.gda.pl>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?

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@...y.mif.pg.gda.pl*