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:
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?
/resin-data/addons/core/snips/asoundrc be used by anything?