DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id;
        b=Izt9Z+pO1jSbuuMyLdlhDVVkz+39jcHkTvpoE9o8iUIijCVjlynHYS+IGzjGEWrGZE4rToKDAnE9WH2vtLdfNmR4mv0CqRPgNgPhyRsbcWn4xKHHy/GUR59WqqMcP1KFaXpzuxSOY9+MR3wR0WCautkURC8VVJnSl8ItutlVvcs=
From: Andreas Hartmetz <ahartmetz@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?
Date: Tue, 26 Jun 2007 22:39:04 +0200
User-Agent: KMail/1.9.7
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200706262239.05070.ahartmetz@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3486
Lines: 74

> > 
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API

> You mean the undocumented, 100% ioctl one?  With one ioctl to write
> interleaved sound, one for non-interleaved sound, in addition to
> setting interleaved or not in the configuration?  I should check one
> day which one wins.

> Or the "library"?  Don't get me started on this one.

> I take your word about the fact that the kernel side is better.

Okay, here's a rant.

As an interested kernel outsider and KDE developer(*), it looks to me like 
most kernel people are  too focused on the history and feature lists of the 
particular technologies here. 

The real matter with ALSA is that you get a strong "ALSA hates me" feeling 
when dealing with it. There is bad documentation, bad API, and a config file 
syntax that is much harder to understand than necessary.

Then there is the kernel/library split that seems to have no convincing reason 
at all in its current form.
Why not put the whole sound system in userland? It has been done before. Sound 
is just not performance critical at all and it's almost never mission 
critical.
Plus you wouldn't have to cross the userland/kernel gap to implement new and 
exciting things that way. Audio is kinda simple on the IO level (I hope I'm 
right there :) ) and, ideally, on the userland API level. These places are 
exactly where well-defined interfaces should be. An appropriate IO interface 
and userland API should be set in stone, not something arbitrary in between. 
Hell, there could even be a source compatible sound driver standard for all 
Unix-like free OS kernels.

The track record of ALSA for me goes like this:

- dmix finally started working automatically (at least on my Kubuntu system) 
about one year ago, about five years after everybody could see that this was 
badly needed. I couldn't get it to work before. The howtos somehow didn't 
work and ALSA's documentation isn't all that helpful.

- Different desktop environments have different sound daemons to paper over 
the weaknesses of ALSA (no dmix by default / unfriendly API), which creates 
new problems. Yes there are other reasons for sound daemons, but I doubt 
anybody would have come up with the idea if it wasn't for ALSA.

- I have an Envy24HT based soundcard in my desktop PC, which also goes to show 
that I'm really interested in sound issues. I have to run alsamixer after 
every bootup to unmute the left channel because restoring volume only works 
for the right channel. The left channel starts working after changing its 
volume.

- On my IBM/Lenovo R50e notebook with Intel chipset sound didn't work before 
I "muted" the "headphone jack sense" control in alsamixer. That took two 
hours or so. When both the master volume and the PCM volume control are set 
to 100% I get really bad clipping problems.

- Some time ago ALSA reported that my soundcard supports sampling rates it 
doesn't in fact support. This was fixed by Takashi Iwai after a week and two 
mails or so. Thumbs up.

Regards,
Andreas

(*) I am not representing KDE in an official way at all, but I can say  that 
KDE developers generally put *much* effort into making APIs as logical and 
friendly as they possibly can.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/