Date:	Wed, 27 Jun 2007 05:59:33 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Andreas Hartmetz <ahartmetz@...il.com>
CC:	linux-kernel@...r.kernel.org, Takashi Iwai <tiwai@...e.de>
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?

On 06/26/2007 10:39 PM, Andreas Hartmetz wrote:

> 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.

I'll agree to the documentation bit; the funny thing is that it's partly 
caused by documentation actually being, or once having been, _better_ than 
it is for the average subsystem. ALSA for example has the useful "Writing an 
ALSA Driver" document from Takashi Iwai:

http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html

Documentation becomes obsolete as code progresses though and yes, especially 
on the userside of things the documentation is slow to follow. And then the 
usual problem of noone ever removing obsolete junk from the web exacerbates 
matters. Google will find you tons of useless, outdated crap but if you need 
the information in the first place, you don't know that it _is_ obsolete.

And yes, this unfortunately includes www.alsa-project.org. For the longest 
time it was advocating writing ~/.asoundrc files for example through generic 
driver boilerplate texts while that was actually at that point mostly 
counter productive in getting ALSA functional.

As to the config file -- well, sure. The best thing about is that normally 
you don't need it...

The "bad API" I find interesting since you are a KDE developer. I'm not an 
audio application developer myself so I don't have (m)any well thought out 
opinions on it, but isn't the only thing in KDE4 that talks to ALSA the 
Phonon ALSA backend? If you are talking in that context, I'm quite sure the 
alsa-user and/or alsa-devel lists (@alsa-project.org) would like to hear 
about any specific comments/problems. Getting the Phonon backend right from 
the start is something that seems important.

> 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

Heh. Sound may not be, but audio is. For the longest time, audio users stuck 
with 2.4 kernels and the low-latency patches that were availabe for it due 
to latency issues. Large parts of ALSA already are in userland in the form 
of libasound and I expect moving over everything would not so much help.

[ ... ]

> 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.

dmix was really only implemented (or at least, made default) for casual 
users. Hope it'll not come across as elitist but people who are serious 
about music or audio don't actually need or want it. It's a consumer thing. 
To have software mixing work you have to resample to a common rate and this 
an absolute unthinkable horror to a serious user. It's a good thing it's now 
default, but only because a majority of sound users is not serious (simply 
because it's mostly all computer users).

> - 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.

Given that they existed before ALSA did this seems to be a somewhat odd doubt.

> - I have an Envy24HT based soundcard in my desktop PC, which also goes to show 
> that I'm really interested in sound issues.

Nice chip. I don't have one, and am not too sure about its native supported 
rates but if you are mostly playing 44100 through it (ie, CD source audio) 
I'd consider doing without dmix. A nice sounding chip like that shouldn't be 
subjected to resampling really. Someone recently informed me on the ALSA 
list that Envy24 indeed doesn't do hardware mixing though, so I guess you 
may need it if you really do want the also have the card available for 
desktop sounds.

> 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.

Sounds like a rather debugable problem. I'm (almost) sure someone will try 
to get you a useful answer if you post to the alsa-devel@...a-project.org 
list :)

> - 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.

First problem I don't know about but is no doubt related to alsa developers 
not having proper documentation. On lots of hardware, there's many bits to 
flip, with no information from the manufacturer forthcoming. You can't hold 
that against ALSA so much.

As to the second bit -- most cards mame any audio that passes through them 
when you set a volume to above 0 dB. dB scales were recently implemented for 
many drivers. If also for yours, I expect 100% is more than 0 dB?

> - 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.

Yes, Takashi Iwai is very responsive.

> (*) 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.

Not so much that I'm likely to be of great help myself, not being an audio 
application developer, but if there's any problem's with the new KDE4 stuff 
in relation to ALSA, I hope you or someone else will bring them up on the 
alsa list(s)...

Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists