Snapcast client container direct to audio output in multi-room

[ChestersGarage]

Hopefully this might address the current issue of glitches and skips, noted here:
https://forums.balena.io/t/snapcast-client-container-direct-to-audio-output-in-multi-room/213436
https://forums.balena.io/t/spotify-tiny-gaps-pauses-in-the-sound/202858

(Copy/pasta from the first forum post above. Please see the post for more details.)
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.

[jellyfish-bot]

[anujdeshpande] This issue has attached support thread https://jel.ly.fish/f4893e91-e70e-4058-84cf-836a5f82981c

[ChestersGarage]

I have a PoC of this working, with great results. See my comment on the forum post linked above.

[tmigone]

Hi @ChestersGarage catching up with this.

I've read through all your posts, awesome work. Let me know if I the main takeaways I got are still valid.

Bypassing the audio block for the output results in:

• Better performance, which is great for low end devices.
• No changes to increased latency after several days of playback

Let's see where we can take this.

[ChestersGarage]

Hi @tmigone,

Bypassing the audio block for output has resolved issues with output latency and drift, and helps performance on older/smaller devices. But it has not addressed the slowly-increasing latency on the input side. Restarting the multi-room server container clears up the input latency. My gut says this is another pulseaudio issue, however.

While performance is improved on slower devices, this change does not make the application stable on those devices. I had to run a build with a custom docker-compose.yml file that eliminates all containers except multi-room client and sound-supervisor for the RPi ZeroW and B+ to be stable. It also cleared up differences in output latency caused by slower CPUs and older architecture, relative to faster/newer devices.

[IIxauII]

Bump, any update on this?