I’m looking at the balenaSound architecture diagram here, and I had an idea I think might help with glitches and skips. I don’t know how feasible this is.
When running in any multi-room mode, route the multiroom-client container’s output directly to the sound output, rather than through the audio block. The audio block is a great management point for audio inputs. But there is only ever one audio output, and it doesn’t change during the life-cycle of a device, under normal usage patterns. Upon reboot or a sound-supervisor reconfig event, the containers are restarted anyway, so reconnecting the correct blocks to the sound output would happen at that time, without any expected conflicts.
This would provide reduced complexity in the audio routing, and it would open up the ability to run a dedicated multi-room client on only the multiroom-client container, which I expect would re-enable support all the way back to the RPi 1.x.
In standalone mode, audio would route through a plugin, then the audio block, then to the sound output, as it currently does.
In multi-room mode, audio would route through a plugin, then audio block, then multi-room server … received by multi-room client, then to sound output.
My rationale here is that I think pulseaudio is just trying to do too much, with how much compute and I/O the RPi has available (or maybe some kind of process or scheduling issue, but that’s beyond the scope of this post). I’ve noticed that even though a device like an RPi 4B has plenty of compute capability to keep up with balenaSound, it still has glitches and skips, which did not exist (as far as I can tell) in the 2.4.x code.