Concurrent sound playback without a sound server

[Michel Dänzer <daenzer@debian.org>]

Inspired by a very good article about ALSA in the German magazine c't
26/2003, I finally got the ALSA dmix plugin working fine and thus rid of
problems with apps blocking each other on sound playback, without
needing any of the sound servers which all are unsatisfactory for me
(not to mention that I couldn't get many of them working correctly at
all on my TiBook). I thought I'd share my experience, hoping it will be
useful for others.

First of all, you need to get ALSA working to the point where you
basically hear correct sound. This shouldn't be hard with the Debian
ALSA packages, in particular with a 2.6 kernel, so I won't go into
details here.

The next step is setting up ALSA to use the dmix plugin (official
documentation at
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dmix). Put something like this in /etc/asound.conf or ~/.asoundrc:

pcm.!default {
        type plug
        slave.pcm dmixer
}
                                                                        
pcm.dmixer {
        type dmix
        ipc_key 1024 # This must be a unique IPC key (see ipcs output)
        ipc_key_add_uid true # UID will be added to IPC key
        slave {
                pcm "hw:0"
                period_time 0
                period_size 1024 # Must be power of 2 for alsa-oss
                buffer_size 8192 # ditto
                rate 44100
        }
}

This sets up a PCM device called dmixer using the dmix plugin and
overrides the default PCM device to use it via the conversion plugin,
which will convert the sound format, rate and number of channels on the
fly if necessary (the dmix plugin only supports a fixed constellation of
these parameters due to the way it works).

Now you should be able to use any number of ALSA apps concurrently. The
problem is that still only a minority of apps use ALSA directly, at
least by default. Luckily, most (can) use a standard library for sound
playback, e.g. SDL; for those, you may have to set these environment
variables:

SDL_AUDIODRIVER=alsa
AUDIODEV=default # This isn't necessary with the default device fix from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225252

For OpenAL, I use

(define devices '(alsa sdl native))

in ~/.openalrc, which tells it to try ALSA first (the current OpenAL
packages in Debian don't support ALSA directly though), then SDL and
only then direct access to /dev/dsp.

So far, so good, but there's still the odd app which can only access
/dev/dsp directly for sound. That's what alsa-oss is for, which
unfortunately isn't available in Debian yet (though I'm told that will
change after the next DeMuDi release, planned for mid January), but
almost as conveniently from

deb	http://apt.agnula.org	unstable	main contrib non-free

(or the corresponding deb-src entry for non-i386 users). It works by
preloading a library (libaoss) which translates direct access to OSS
devices into ALSA library calls. It provides a script called aoss, but
you probably want to add /usr/lib/libaoss.so to the LD_PRELOAD
environment variable. It also requires the following additions to the
ALSA configuration:

pcm.dsp0 pcm.default
ctl.mixer0 "hw:0"


The major remaining problem for me is that xine doesn't work well with
dmix, see http://sourceforge.net/mailarchive/message.php?msg_id=6793623.


My main usage scenario has been listening to music with alsaplayer while
playing armagetron. :)


Happy dmixing, and Happy New Year!


PS: I'm not subscribed to the debian-user list.

-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Software libre enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer