> >
> > 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 [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]
