One thing missing from the sound configuration was the ability to handle multiple sound streams. Until now, when 2 processes tried to produce sound, second needed to wait until the first unlocked the sound device. Googling for existing sound daemons (
arts for KDE,
esd for Gnome), I found out that I don't actually need a daemon, as ALSA provides a "plugin" for mixing the streams called
dmix. Right now my .asoundrc file looks like that:
# 'dmix' plugin for easy mixing of sound streams
pcm.ossmix {
type dmix
ipc_key 1021
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 8192
rate 48000
}
# bindings are cool. This says, that only the first
# two channels are to be used by dmix, which is enough for
# (most) oss apps and also lets multichannel chios work
# much faster:
bindings {
0 0 # from 0 -> to 0
1 1 # from 1 -> to 1
}
}
# redirect to ossmix
pcm.dsp0 {
type plug
slave.pcm "ossmix"
}
# redirect to ossmix
pcm.!default {
type plug
slave.pcm "ossmix"
}
ctl.mixer0 {
type hw
card 0
}
The applications that use sound devices need to be re-configured: XMMS uses ALSA as an output plugin with 'default' as audio device, I also switched
play utility into
aplay, one that comes with ALSA.
Mplayer settings: in
/etc/mplayer/mplayer.conf I added the following:
ao_device="alsa:ossmix"
Quakeforge is not working properly by default. According to this excellent
short howto, it needs to be reconfigured to use OSS sound plugin (add option
set snd_output oss in
/etc/quakeforge.conf). Then you need to do this trick, I guess to tell the kernel sound subsystem that Quakeforge needs to access the device exclusively:
echo "nq-glx 0 0 direct">/proc/asound/card0/pcm1p/oss
This means that quakeforge will take over the device (so that, eg. it will
not be possible to listen to any MP3s) but I guess it is all right.
Some more info how to setup other applications, look
here