I’d like to share a small extension I’ve just released.
It’s called Mopidy-Snapduck and it serves two purposes:
- stop Snapcast client when Mopidy starts playing
- start Snapcast client when Mopidy stops playing
It works by executing and terminating snapclient directly, so you should disable any snapclient system-wide instance when using this extension.
Why would I need that?
I have a multi-room configuration very similar to this one:
Room-local speakers are RPis Zero W with their own Mopidy instance for local playing. But I didn’t want to mute Snapcast everytime I want to play something in a room speaker (while keeping the central system playing). Muting the local audio device would require support for multiple platforms (ALSA, PulseAudio, etc.) so I decided to go with killing and restarting the snapcast client when needed. Besides, muting would not prevent audio packets from coming in (which is useless network traffic at that point since we’re not going to play them). Also I didn’t want to contact the Snapcast server just to tell it “hey, mute me!”.
To summarize:
- when Mopidy is started, a snapclient instance is started
- when Mopidy starts playing, the snapclient instance is killed
- when Mopidy stops (not pause!), snapclient is started again
- when Mopidy is stopped, the snapclient instance is killed
I developed this extension because of my requirement described here: https:(can’t post more than two links)…github.com/badaix/snapcast/issues/788 but also because I wanted to learn a bit about Mopidy extension development. I’ll be glad to talk about any suggestion anyone can give on how to better implement this use case.