ALSA dmix setup


I changed from a PC with a trident sound card capable of playing back multiple sound streams at once to an integrated sound card based on the intel i810 device. Sadly, the i810 only plays a single sound stream, and requires software mixing to accomplish multiple-application sound.

With the competition between esd, arts, sdl, alsa and oss, I decided to look into ALSA's new dmixer plugin, alongside aoss to force oss-using applications to use ALSA's native driver.

Without too much trouble, I achieved the goal of simultaneous sound playback from the applications I commonly use.

Software Versions

Basic ALSA Setup

Following the excellent guidelines on the alsa dmixer page, I setup my personal .asoundrc as follows:

pcm.ossmix {
    type dmix
    ipc_key 1021          # must be unique!
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024  # must be power of 2
        buffer_size 8192  # dito. It
        #format "S32_LE"
        #periods 128      # dito.
        rate 48000

# bindings are cool. This says, that only the first
# two channels are to be used by dmix, which is enough for
# (most) oss apps and also lets multichannel chios work 
# much faster:

    bindings {
        0 0   # from 0 => to 0
        1 1   # from 1 => to 1

# Redirect to ossmix
pcm.!default {
    type plug
    slave.pcm "ossmix"     # use our new PCM here

# Redirect to ossmix
pcm.dsp0 {
    type plug
    slave.pcm "ossmix"     # use our new PCM here

# mixer0 like above
ctl.mixer0 {
    type hw
    card 0

This gives a new alsa device called 'ossmix', which can be openned by multiple applications at once, and is software mixed down to 48000Hz. The section for !default also redirects default alsa accesses to the mixed device.

Once this was setup, it was just a case of configuring the sound-using applications to select this device.


This was an easy one, as Myth has support for ALSA natively. The trick is to specify the output sound device as ALSA:<alsa device> in the front-end, and to make sure alsa support is enabled in the when you compile.

  1. Start up mythfrontend
  2. Select Setup, then General
  3. Change the Default Audio Output entry to ALSA:ossmix or ALSA:default
  4. Change the Mixer name to 'default'

After this, try watching live tv, or playing back a recording. You should hear the sound as normal.


I use the ALSA native support plugin for XMMS, so it is just a question of installing it, and then selecting the output device.

  1. Start xmms, and open the options->Preferences dialog.
  2. Select the ALSA ouotput plugin on the Audio I/O Plugins page.
  3. Open the configuration page, and type in 'ossmix' or 'default' for the audio device.

Once you have done this, start xmms playing a file, then go back to mythtv and watch a recording. Both should play simultaneously.


Mplayer also has native alsa support, so it is a question of just selecting ALSA for sound output, and the ossmix or default device. Depending on your version of mplayer, the alsa audio output module can be called many things.

  1. Run mplayer -ao help, and find the name of the alsa module. For example, alsa9, alsa1x, etc.
  2. Use -ao <alsa module>:ossmix or -ao <alsa module>:default to select the right device. Eg, mplayer -ao alsa1x:ossmix <file>
  3. Add a line to the ~/.mplayer/config file to setup a permanent option. Eg, ao=alsa1x:default

You can try running multiple mplayer streams at once with this change.


Xine has native support for alsa, so it is just a question of using it.

  1. Start xine, and open the Settings->Setup dialog
  2. On the audio tab, scroll down, and select 'audio driver to use' as alsa.
  3. Optionally, set the alsa_default_device to ossmix.
  4. Optionally set the resampling to 48000Hz.
  5. Restart Xine

VMware 3.*

VMware does not support alsa natively, so in order to correctly use the alsa-only dmix device, VMware needs to be started using the 'aoss' wrapper, that intercepts applications trying to use OSS sound, and converts them to ALSA transparently.

Usually, it is just a question of using 'aoss <program>', but VMware is also setuid, so the library pre-loading trick that aoss uses fails.

In order for an suid-program to pre-load a library, two conditions have to be satisfied:

With a default install of the aoss wrapper, neither of these conditions are met. I made the following change to the aoss script:


# A simple script to facilitate the use of the OSS compatibility library.
# Usage:
#	aoss exec "$@"

Note that this only works if you have libaoss installed into one of the system library directories. I also made the library suid.

With both of those changes, starting VMware using 'aoss vmware' redirects the oss calls to the alsa default device - but as we have seen, this is automatically routed to the ossmix software mixer, so it works as-is.

VMware 4.*

It is reported the above trick does not work for this release of VMware. However, there is a new module available called 'vmwaredsp', which provides wrappers to direct VMware sound to either the 'esd' or 'artsd' software sound mixers. It can be downloaded from, and then you need to compile and install it.

I did not get the wrapper to work with artsd, but it did work perfectly well with the esd wrapper. The following script configures both artsd and esd to use the multiplexing ALSA driver.

# Script to restart any existing multiplexers

killall -9 artsd
killall -9 esd
sleep 1
esd -nobeeps -as 2 -r 48000 -d ossmix &
sleep 1
artsd -a alsa -r 48000 -s 5 -V 100 -S 4096 -F 64 -D ossmix &

After this, start vmware as follows:

vmwareesd [<configuration file>]

instead of

vmware [<configuration file>]

Hope that helps!

Valid XHTML 1.0! Valid CSS! Maintained by Mark Cooke
Last Updated: 16-Aug-2005