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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected] 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux