Log in
15
February

You can have sound or sound, but not both

Written by Jason 'vanRijn' Kasper. 2 comments Posted in: Life in General

Like many other things, sound in Linux is not nearly as easy as it should be. Briefly, the problem is that many/most sound cards in computers these days do not do hardware sound mixing. This means that they are physically unable to handle 2 or more programs trying to ask it to play sound at the same time. Windows gets around this by having software mixing built into its sound card drivers (or kernel–who knows where it actually is). I imagine that Mac OS X does this too. And of course, for these 2 commercial (read: expensive) operating systems, this all Just Works without the user having to get involved. In fact, most Windows users no doubt have absolutely no clue about software mixing and hardware mixing. And so it should be, IMHO.

So, there’s the crux of the problem: sound card makers have gotten away with making cheaper sound cards that can’t handle multiple inputs at the same time.

Linux has several answers to this problem, depending on how you want to handle it. And therein lies the second part of the problem–the user has to know about it and decide and configure it all to work.

There are several software sound mixers for Linux: aRts (which the K Desktop Environment uses), esound (which the GNOME desktop environment uses), the JACK sound daemon, and finally the alsa dmix plugin that is included in the Linux kernel itself. For an example of the confusion around just one of these layers (alsa), look here. And the biggest problem is that none of these solutions is 100% foolproof. All of them require that the programs that are trying to produce sound either know about these specific sound solutions, or require the user to run special commands that override the program’s sound API layer. And all it takes is for one program to not play nicely with this mish-mash, and you’ll find that none of the other programs are able to play sound (i.e. it will lock the sound card and not allow any other programs to access it).

Anyway, I have spent time this last weekend in getting rid of aRts (the KDE sound daemon) and now use the alsa dmix plugin entirely. It’s a thoroughly confusing process that, at the end thereof, I still don’t understand completely. Here’s my $HOME/.asoundrc file:

pcm.ossmix {
type dmix
ipc_key 1234
slave {
pcm “hw:0,0″
period_time 0
period_size 1024
# — vR — 2005-02-13 : lowered this from 4096 to 1024 to get rid of
# skipping and “ALSA: underrun, at least 0ms.” errors
buffer_size 1024 # buffer size < 6653, but pow(x, 2)
buffer_time 84000
rate 44100 # we want to play CDs only
}
bindings {
0 0
1 1
}
}
pcm.duplex {
type asym
playback.pcm "ossmix"
capture.pcm "dsnoop"
}
# Everything shall be dmixed, so redefine "default":
pcm.!default {
type plug
slave.pcm "duplex"
}
# OSS via aoss should d(mix)stroyed:
pcm.dsp0 {
type plug
slave.pcm "duplex"
}
ctl.mixer0 {
type hw
card 0
}

The above came mostly from the amaroK alsa/dmix wiki page. And things seem to be working fairly well. Below are my random thoughts and semi-rants on the whole thing then….

2 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. vanRijn

    Found this today… It looks kind of interesting. I suppose I might get bored enough at some point to try it. http://fort.xdas.com/~kor/oss2jack/

    Wednesday February 16, 2005 at 12:19 am
  2. Jason 'vanRijn' Kasper

    Also, an update to the esound issue…. After reading a comment somewhere (sorry, don’t remember where), I’ve recompiled the esound source RPM with –disable-alsa. This isn’t the best way to do it (seems counter-productive, really), but then I run esound with “aoss esd” and it works perfectly. No stuttering/garble/static/etc. from esound. Flash from my browsers now works perfectly too as a result.

    Yay for silly workarounds!! =:/

    Sunday February 20, 2005 at 12:27 pm

Some HTML is OK

or, reply to this post via trackback.

 
« »