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….

• I’m using amaroK for my music player. Congrats on the 1.2 release, guys!! amaroK is absolutely the best music player that I’ve seen for Linux so far, and I’m thrilled with it. I am using the xine plugin for amaroK. I very much wanted to use the gstreamer plugin, having heard so many good things about it, but it simply does not work for me and I don’t know why and neither did the folks in the #amarok irc channel. xine uses alsa correctly, and thus amarok uses alsa correctly.
• I have turned off the aRts sound server in KDE’s control center. I tried to get it to use alsa’s software mixing (dmix) so that it would not block my sound card (keep other programs from being able to access it), but I don’t think I was successful. At any rate, this was at the beginning of the experiment, so… I can’t recall whether I just ditched it to learn or ditched it because it didn’t work. I think I ditched it mainly after hearing that the aRts programmers were looking to get rid of aRts.
• I have configured knotify (the System Notifications in KDE’s control center) to use an external player, rather than using the aRts layer. I am using mplayer, which is set up to use alsa as it’s audio output, so that doesn’t block my sound card. This all means that all of KDE’s cute little sound notifications work just fine without having to have the KDE aRts sound server running.
• Apparently, the Flash browser plugin for Linux will only work if the GNOME esound sound server is running. Fortunately, esound (esd) plays nicely enough with alsa that this doesn’t block my sound card now. This is wonderful news, since previously (when I was using aRts as my sound server), I could never hear sounds from the Flash plugin. My only complaint is that esd seems to have some issues with alsa, like sound skipping, etc. But for the most part, most Flash sounds aren’t full-length Beethoven symphonies anyway, so this isn’t so bad.
• And then there’s vmware. I’m using the new workstation 5 beta, pretty happily, for those rare occasions when I have to use something that is only written for Windows. Quicken 2005 is the biggest offender for me. Vmware does not use alsa as an audio output (can you guys PLEASE fix this???), so it demands the use of /dev/dsp, which in my case is not possible, since that would not allow any other program to use it. Now, I’ve seen that there is a plugin for vmware that is supposed to allow this to work by getting vmware to use esd or aRts. I’ve tried getting this to work, but it does not, and my guess is that it’s because I’m using the newer workstation 5. Bummy. So, sound still does not work for me in vmware.