Audio output with Linux, the 47th.
One of the things that gives me the creeps every now and then is audio-output on a linux-system, that is, at least on my system. Seems that I’m not alone with this. Eugenia from osnews.com posted a rant to the alsa-devel mailinglist some time ago and she surely had some valid points. Anyhow, I don’t want to complain, what’s following is just my own perception; your mileage may vary.
It’s not like basic audio output itself, no matter if using OSS (anyone still using it with a current kernel? OK, who cares about it beeing depriciated.. 
) or ALSA, is difficult to set-up. It’s the “exotic”(!?) stuff you never thought about when using other operating systems. Maybe other distributions provide solutions that work out-of-the-box but getting multiple applications to output to a non-h/w-mixing capable sounddevice can be a real pain on the local Debian installation. And before some smart person comes up with it: no, there’s simply no space left in my XPC to put in a cheap Soundblaster with h/w-mixing capabilities. Long story short: this is about watching videos without having to quit my audio player using the hardware at hand.
Using KDE, ARTS would be the most likely sound damon candidate, but IMHO arts is just an outdated multimedia-framework. It lags on various tasks and it’s installed here only because some KDE-applications depend on it. There’s no active development taking place for arts and rumors spread that gstreamer (gst) will be the multimedia framework of KDE 4.0. Keep in mind that gst is no sound-daemon. Outputting directly to ALSA anyway, this is fine with me.. sort of.
I prefer amaroK for audio and mplayer and xine for video playback. When using libxine as engine for amarok, everything works fine. libxine releases the audio device when paused/stopped so amarok can remain in my systray while allowing other applications to access the sound device. This was my system’s setup for the last few months.
Lately I find gst more appealing. It provides more functionality like crossfading, parsing of ogg-stream metadata or support for musepack (for xine, mpc is only available via cvs). Besides that it seems that the amarok-devs focus mostly on gst when it comes to new engine-dependent features. The drawback: gst does not release the audio device on pause/stop, and therefore amarok needs to be shut down before calling another app that requires access to the sound device.
The obvious solution is ALSA’s Dmix plugin which enables software-mixing of different streams. The site explains how to set it up and covers problems with special chipsets and applications. Fine. I did that some time ago but for using libxine my .asoundrc laid around in ~, unwanted, therefore renamed and nearly forgotten. Restoring the file and setting dmix as amarok’s output device, the sound was nothing but choppy. The friendly guys over at #amarok pointed out that increasing the buffer sizes might help and indeed, that did the trick for amarok.
Unfortunately, mplayer was not nearly as cooperative. I tried using ao=alsa:device=plug=dmix for mplayer and indeed it started playing parallel to amarok, but the video was skipping. The only way to get around it was shutting down amarok which to prevent was, you might remember, the reason for doing this whole thing in the 1st place. I took a look at /etc/mplayer/mplayer.conf and there it was: autosync=30, commented out along with ao=arts. Autosync had enabled relatively smooth playback when still using ARTS, but when I dumped ARTS I commented the whole thing out. After uncommenting it and setting the appropriate line for audio-output: et-voila! mplayer played back relatively smooth, more testing to come.
Like most problems I run into on my system this whole thing tells me two things: While it’s possible to get anything running the way you like it using GNU/Linux, well, at least to some certain amount, sometimes the energy you have to put into it seems plainly ridiculous. On the other hand, I just can’t use the easy solutions, can I?
The appropriate configuration files, just in case:
$ cat ~/.asoundrc
pcm.!default {
type plug
slave.pcm "dmix"
}
pcm.dsp0 {
type plug
slave.pcm "dmix"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
period_time 0
period_size 4096
buffer_size 32768
rate 48000
}
bindings {
0 0
1 1
}
}
ctl.mixer0 {
type hw
card 0
}
$ cat /etc/mplayer/mplayer.conf #use XV for video output vo=xv #use alsa's dmix for audio autput ao=alsa:device=plug=dmix #prevent skipping autosync=30 #normalize volume af=volnorm