[MPlayer-users] -ao alsa1x feature or bug?
Adar Dembo
adar at stanford.edu
Tue May 4 02:42:54 CEST 2004
Hey guys,
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.
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.
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?
-Adar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20040503/7d41ed4a/attachment.htm>
More information about the MPlayer-users
mailing list