<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Hey guys,<BR>
<BR>
I'm using the latest version of mplayer through Christian Marillat's debian packages. It is 1.0.pre4 (YAML). In this version and in previous versions, ALSA output seems to misbehave when you have redefined the default device via an ~.asoundrc file or through /etc/asound.conf. In particular, I've redefined pcm.!default to go through a slave.pcm of type dmix, so that I can mix multiple sounds in software (As my hardware drivers do not support hardware mixing). Most applications that leverage alsa will output to the "default" device, hence, their sound will get mixed with everyone else's sound.<BR>
<BR>
With mplayer, this system seems to be bypassed. If I specify -ao alsa1x, either in mplayer.conf or through the command line, mplayer's sound output is not sent to dmix, and if I try and play another sound, my other sound app will hang waiting for the sound device. If I specify -ao alsa1x:default, it does go through dmix, and my other sound apps play sounds together just fine.<BR>
<BR>
This leads me to believe that mplayer is outputting to the ALSA device "hw:0,0" which, unless you've written an ~.asoundrc file, is the same as "default". However, in my setup, I've changed "default" to leverage dmix before being outputted to "hw:0,0". Most apps that I use that use ALSA (such as XMMS, NWN, aplay, Totem) output to "default", so that any change in the ~.asoundrc setup are transparent to the app. Not so to mplayer. Is this done on purpose? Or is it a bad way of handling ALSA output?<BR>
<BR>
-Adar
</BODY>
</HTML>