Multiplexing audio between containers


I have two containers running, and which ever is the first to play audio, holds audio, and if I were to use play for instance, I receive the following error:

ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
Arithmetic exception (core dumped)

I have created the following within the root resin-OS /etc/asound.conf rebooted and not had luck sharing/multiplexing audio sent by multiple containers:

  pcm.dsp {    
      type plug    
      slave.pcm "dmix"

Does anyone have any ideas or input?



1 Like

Hi @mbrownnyc, what version of resinOS are you running two containers? Is it a version managed on, or the open source, unmanaged version? How are you starting the two containers? (is it possible to check out what code are you running on the device?)

Thanks for your reply:

root@hassio:~# cat /etc/*release
NAME="Resin OS"
PRETTY_NAME="Resin OS 2.3.0+rev1"

This is the home-assistant image ( which I assume is an unmanaged version.

The containers are started automatically upon boot.

As I didn’t create the containers or the resinOS image, I’m a bit at a loss on specific details.

I have no issues with ALSA and sound access within the containers; I would figure it would be fairly simple to allow multiplexing of audio to both containers. This is my first dive into docker though, but if I understand correctly, containers are not VMs, they are somewhat virtualized filesystems only (?). So I’m not sure why the above /etc/asound.conf dmix implementation doesn’t work.

Any assistance or direction is appreciated.


I see, that’s useful info. Will have to check how the home-assistant image is created…
Probably modifying the underlying resinOS image is not the completely correct way to fix this, but definitely good for debugging.

I’ve seen that the ArchLinux wiki (which has a lot of great Linux knowledge, regardless of distro) as some info on simultaneous playback: and also linking to upstream maybe

I would guess that the above change you mentioned is not totally correct (or rather, not all the changes that are needed).

Definitely need some more investigation.

Thanks for your reply. The resinOS image they use does not have apt-get or alsatools installed. The containers that can access sound are Alpine and Debian. Again, I’m not sure who goes where… as in… I’ve read that docker containers are “not VMs!” But, if they were VMs the responsibility for sharing a hardware resource is on the host OS, in this case (well not this case because containers are not VMs) that responsibility would be on resinOS.

However, alsa or alsa-util are not installed in resinOS:

  root@hassio:~# find / -iname *alsa* |  grep -v docker

I’ve added the following to /etc/asound.conf on both containers:

pcm.dmixer {
    type dmix
    ipc_key 1024
    ipc_key_add_uid 0
    ipc_perm 0660
pcm.dsp {
    type plug
    slave.pcm "dmix"

I’ve also installed and switched to using alsamixer on mopidy.

I am able to use aplay to play a wav from the same container where mopidy is playing music… to me this proves the issue isn’t the process locking ALSA, but the actual container locking ALSA. Although, inspecting files below /dev/snd/ shows a PID locking audio that isn’t listed in ps within the resinOS, but when killed stops Mopidy from playing (of course).

How is the hardware virtualized/multiplexed (for lack of better terms) between docker containers?

Would /resin-data/addons/core/snips/asoundrc be used by anything?



I was advised in #alsa on freenode to look at using the ipc switch to share memory between containers.

Is it possible to provide guidance on using that with /dev/snd/?



Is there already a solution for this interesting problem ?

I am referring to the generic problem where we have multiple containers that want to share the same audio device (e.g. speaker , microphone).

Hello, we don’t have any experience with this, but an idea is to maybe set up something like pulse audio in one container and then have all other containers connect to that.