#Stuttering local audio in docker

1 messages · Page 1 of 1 (latest)

ocean burrow
#

I could use some pointers in troubleshooting stuttering when using the local audio provider. My setup is as follows.
Ubuntu based host machine running docker.
MA run as a docker container with /dev/snd passed through to it.

HDMI connection from the ubuntu host to my audio receiver.

If I run the sendspin daemon directly on the host, audio plays normally with no stuttering. If I instead use the local audio provider, audio stutters every couple seconds, and music barely plays at all.

Completely understand if this is just not a supported configuration, but I'd like to try to get it working if possible.

I don't see anything crazy going on in the logs:

2026-04-13 12:47:32.649 INFO (MainThread) [music_assistant.Local Audio Out] Setting active output protocol on HD-Audio Generic: VSX-530 (hw:0,7) to Sendspin
2026-04-13 12:47:32.651 INFO (MainThread) [music_assistant.player_queues] Resumed queue HD-Audio Generic: VSX-530 (hw:0,7) from playlog (userid match)
2026-04-13 12:47:32.653 INFO (MainThread) [music_assistant.streams.audio] Start Queue Flow stream for Queue HD-Audio Generic: VSX-530 (hw:0,7) - crossfade: disabled 
2026-04-13 12:47:32.695 INFO (MainThread) [music_assistant.Local Audio Out.bridge.HD-Audio Generic: VSX-530 (hw:0,7)] Bridge writer started for HD-Audio Generic: VSX-530 (hw:0,7)
inner cloak
#

Could be as simple as setting some alsa settings.
For example @latent stirrup also had to make some modifications to the alsa config file to get his setup to play correctly.

#

We should explore what else we need to set/configure for the local audio provider

ocean burrow
ocean burrow
#

So I did a bit more digging, and it looks like there are commits to PortAudio for PulseAudio, but there is not yet a release which includes them. Hopefully pulse audio will just be part of port audio soon, and therefore the pypi sounddevice library as well.

I still need to figure out where my stutter problem is coming from, but I'll set aside my pulse audio adventures for now.

#

Interesting, so I tried running the server without using docker. If I use the default ALSA device it sounds great. But if I use the device for my receiver specifically then I get the stuttering playback.

 0 HD-Audio Generic: HDMI 0 (hw:0,3), ALSA (0 in, 8 out)
  1 HD-Audio Generic: VSX-530 (hw:0,7), ALSA (0 in, 8 out)
  2 HD-Audio Generic: HDMI 2 (hw:0,8), ALSA (0 in, 8 out)
  3 HD-Audio Generic: HDMI 3 (hw:0,9), ALSA (0 in, 8 out)
  4 HD-Audio Generic: ALC897 Analog (hw:1,0), ALSA (2 in, 2 out)
  5 HD-Audio Generic: ALC897 Alt Analog (hw:1,2), ALSA (2 in, 0 out)
  6 hdmi, ALSA (0 in, 8 out)
  7 pipewire, ALSA (64 in, 64 out)
* 8 default, ALSA (64 in, 64 out)
#

So device 8 above works, but device 1 does not.

#

None of these are even listed in the Ubuntu GUI (I'm guessing because it uses pulseaudio and handles them differently).

#

I think default is probably using device 7, and 7 also works as expected directly.

ocean burrow
#

Hmm... so in the docker container if I just map /dev/snd, I only see these devices in the container using the python sounddevice library:

< 0 HD-Audio Generic: HDMI 0 (hw:0,3), ALSA (0 in, 8 out)
  1 HD-Audio Generic: VSX-530 (hw:0,7), ALSA (0 in, 8 out)
  2 HD-Audio Generic: HDMI 2 (hw:0,8), ALSA (0 in, 8 out)
  3 HD-Audio Generic: HDMI 3 (hw:0,9), ALSA (0 in, 8 out)
> 4 HD-Audio Generic: ALC897 Analog (hw:1,0), ALSA (2 in, 2 out)
  5 HD-Audio Generic: ALC897 Alt Analog (hw:1,2), ALSA (2 in, 0 out)
  6 hdmi, ALSA (0 in, 8 out)
#

So it looks like the only working devices are simply not seen.

latent stirrup
#

Hi, I added this to my docker run

# 
-v /home/vingerha/docker/music_assistant_beta/asound.conf:/etc/asound.conf \
#

and asound.conf contains:

# 
pcm.denon_buffered {
    type plug
    slave {
        pcm "hw:0,3"
        rate 48000
#        channels 6 /// careful as this forces 6 channels even when stereo is offered
    }
}

pcm.!default {
    type plug
    slave.pcm "denon_buffered"
}
#

This allows me to play to 'default'. From your devices, you would need to change this to hw:0,7.

#

Challenges on my hp/intel-laptop/ubuntu: power mgt, I switched off all as it made the hdmi unavailable after a while, requiring reboot or manual intervention on the prompt. Other one is keeping the connection alive when I switch my receiver to another hdmi port, this now sometimes (I did not time it yet) re-start the play

ocean burrow
#

hw:0,7 wouldn't work for me as that is the device that gives the stuttering audio even if run outside of the docker container.

latent stirrup
#

yes...hence the asound.conf... then restart the container

ocean burrow
#

hmm, I guess I don't understand

latent stirrup
#

MASS sends 44.1 and hdmi requires 48k

#

the asound will resolve the mismatch

ocean burrow
#

I see. Thanks, that might be a good workaround. Since MA is able to see the pipewire device when I run it outside of the container, I'm trying to find a solution to allow it to see the same device inside the container. I think I am getting close.

latent stirrup
#

I am pure alsa on my machine, deinstalled pipewire/plumber

ocean burrow
#

I see. Since I am just using the default config on Ubuntu, I'd like to get it working so MA just works out of the box with it.

latent stirrup
#

just try it I would say 🙂

#

Noting that from MASS side this is a very early beta setup so bound to have challenges

#

Also kodi and mpd have their trickeries on my laptop, same issues with deconnect power/port-loss.

#

koid/mpd resolve a part by sending continuous low level signal to the hdmi port, keeping it alive

#

and on a non-laptop and/or non-intel machine it may work differently too.

ocean burrow
#

Ok, so I got it working. I had to add this dependency to the container.

FROM ghcr.io/music-assistant/server:latest

RUN apt-get update && apt-get install -y \
    pipewire-alsa \
    && rm -rf /var/lib/apt/lists/*

And then a docker-compose.yaml with the following additions:

 user: "1000:1000"
 volumes:
      - /run/user/1000:/run/user/1000
      - /home/fredward/.config/pulse/cookie:/root/.config/pulse/cookie
 environment:
      - PULSE_SERVER=unix:/run/user/1000/pulse/native
      - PULSE_COOKIE=/run/user/1000/pulse/cookie
      - PIPEWIRE_RUNTIME_DIR=/run/user/1000
      - XDG_RUNTIME_DIR=/run/user/1000
latent stirrup
#

Nice, the reason for me sticking to alsa is that my laptop is purely used for MA / MPD (multi-channel) and alsa is said to be the purest way to get data to my receiver (esp. multichan). Pipewire does offer more flexibility and avoids locking as I now have. It would be good to know (also for others) if this setup preserves the availability of the hdmi port even when you restart MA or switch your receiver.

ocean burrow
#

I'm not sure how I would test that, any suggestions?

latent stirrup
#

So, with me (before all the tweaking), the hdmi sink died after not being used for some time (I am not sure but likely an hour??), even when the receiver was still on the same hdmi channel. The other one is when I stopped playing and I switched the receiver to use another port (e.g. tv/etc.), on laptop side it would die too. Other reasons were going in sleep-mode, lid closing, hibernate, etc. Alsa is apparently not the easiest to get your connection back. Atm the laptop is always on, no sleep/hibernate/etc. and for kodi/mpd it is sending a continuous signal, that seems to work. For MA, I still loose the connection from time to time.

ocean burrow
#

Hmm, so with my setup it is running on a little NUC box with no power saving enabled. I'm not sure I would be able to get it to lose the signal in the first place. I guess I'll keep an eye out for any weirdness like that, and do some longer testing today and switch inputs etc.

#

Thanks for your input on this issue, much appreciated.

#

I had to disable CEC and ARC because with my receiver if the tv is turned off then it switched to a different input, but that is unrelated to this issue really.