Monday, April 18, 2005

New sound setup

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:


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


Post a Comment

<< Home