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

From: Rene Herman
Date: Wed Jun 27 2007 - 22:02:16 EST


On 06/28/2007 02:18 AM, Patrick Draper wrote:

Please always use Reply-to-All on this list -- subscribers here like to also get personal copies.

Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by default for some time now so we're talking history anyway. You want mixing on your card? You got it.

I've been following this discussion with some interest, to learn more about ALSA. I've been creating startup scripts for all of my sound-using applications which look like this:

LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"

I found that without libaoss.so preloaded, I wasn't getting software mixing at all.

This would seem to indicate that your alsaplayer (what's in a name) is setup to output to OSS and not to ALSA...

The OSS interface -- consisting of direct access to device nodes such as /dev/dsp0, /dev/mixer and /dev/music -- is an older interface for sound on Linux. The newer ALSA interface works via a library API and is best used natively. For backwards compatibility though, ALSA also provides emulation of the older OSS interface.

It does so in two different ways in fact -- the first one is a direct kernel space emulation where ALSA interprets accesses to those device nodes it then manages much like real OSS would do. This kernel space emulation is made available through the "OSS PCM/Mixer/Sequencer API" you see as options in the ALSA kernel configuration menu.

The other way is a userspace emulation through the libaoss.so library that you are using. That library catches accesses to the OSS device nodes in userspace and translates them to ALSA accesses before they even get to the kernel.

ALSA does software mixing (the act of mixing two seperate streams together to form one) in userspace and as such, the kernelspace OSS emulation does not support software mixing, while this userspace emulation does -- if your ALSA default device is setup for software mixing (it is by default these days) this also works for this libaoss route. If you run a OSS program without the library preload it's using the kernel emulation though.

So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload.

I don't have alsaplayer installed (wasn't that thing dead?) so I can't walk you through its configuration easily, but I suppose you'll be able to figure it out. If you need to specify an ALSA device somewhere, make sure it's not the old "hw:0" but "default" (or "default:0" for the first card, "default:1" for the second, ...). The "hw:N" devices don't do mixing.

I'm constantly running an MP3 player, and with that library I can get
sound alerts from other apps too.

I myself mostly use the ogg123 and mpg321 command line players, both based on libao and thereby only a simple:

$ echo "default_driver=alsa09" >/etc/libao.conf

away from being native ALSA players.

I don't understand exactly what you mean by ALSA mixing by default. I have the OSS Mixer API selected during kernel compiles. Is that what you
are referring to?

No. That's part of the kernel space OSS emulation. A "mixer" in that context is the part of a soundcard that controls volumes and may mix the output of several parts of the card/chip for playback and its inputs for capture. Ie, that which is controlled by a mixer application such as the (ncurses) ALSA reference mixer "alsamixer" or the mixer your desktop environment provides.

Once you have everything running as a native ALSA application you could disable that option. In fact, since you're using the userspace emulation, you could already. The new-ish Flash Player 9 (important for youtube these days) for Linux is also an ALSA application and since I use it, I myself haven't needed OSS emulation for anything anymore.

Rene.

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