search

balena-io-experimental / balena-sound

Build a single or multi-room streamer for an existing audio device using a Raspberry Pi! Supports Bluetooth, Airplay and Spotify Connect
https://balena.io/blog/turn-your-old-speakers-or-hi-fi-into-bluetooth-receivers-using-only-a-raspberry-pi/
MIT License
2.39k stars 427 forks source link

Snapcast client container direct to audio output in multi-room #354

Open ChestersGarage opened 3 years ago

ChestersGarage commented 3 years ago

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 commented 3 years ago

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

ChestersGarage commented 3 years ago

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

tmigone commented 3 years ago

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:

Let's see where we can take this.

ChestersGarage commented 3 years ago

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 commented 1 year ago

Bump, any update on this?