I’m using mopidy now for about a year and i’m quite happy with it. I’ve setup a multiroom audio system based on mopidy in my home and wan’t to share idea. Maybe it could be included in Mopidy somehow. Basically this solution consist of one master device and couple of slave devices. The master device act as an audio source and slaves acts as audio recievers. All devices runs Mopidy, plus master device runs rtspserver service based on this code (Mopidy sends audio to this rtsp server, and rtsp server sends audio to all connected clients). All clients can use Mopidy normally or choose to play rtsp source stream to play the same audio in sync. So if You put a client in every room you can have different music played in every room or the same music in choosed/every rooms. The master device can also play audio in sync if it will use the same rtsp source (of course not with Mopidy instance that serves the audio for rtsp server, but maybe with another Mopidy instance or just a simple gst-launch command). Of course there is more to explain, but I think that thats enough to get the idea. Oh, and with rtsp and gstreamer You can send lossless or compressed audio, depending on your connection bandwidht, wifi can be tricky, i’m using compression and 5GHz band wifi (802.11ac) and it works 99.9% of the time without any glitches and sync issues. Using etherenet cable propably 100%.
As for the integration of this into Mopidy I’m thinking about some kind of ‘Share’ button that will start the rtsp server and clients that could display avaliable rtsp sources (using avahi ?).
Tell me what You think about this ?
Some people on here have been using snapcast for synchronised multi-client audio. The tricky part with that is for the slaves to switch between using Mopidy and snapclient for their audio output. Neither program has any on-play type hooks which you could use to stop the other (like shairport-sync does in pimusicbox). Your setup does avoid this. I don’t know enough about snapcast and RTSP to evaluate the different approaches
As for your integration, why bother with the share button? Just run the RTSP server in the background and advertise it (via MDNS or whatever). You could write a Mopidy backend that listens for those service announcements and provides a library of available streams.
This is how I have it now. And if You use the master device only to broadcast audio and not to play it on the device, this is perfectly fine, but if You want also to play audio on the same device in sync with others then you have to use the rtsp stream (for example by launching gst-launch commad), and then You have a delay related to rtsp protocol (i’m using 0.5s delay). This delay might be annoying if not using multiroom, so i think it would be good if it could be configurable at runtime.
With Snapcast you can run the client and server on the same box as Mopidy. Then you can choose which server the client streams from, it’s own Mopidy instance, or another. That way you don’t have to switch between outputting directly from Mopidy to the soundcard for a client to stream from it’s own server.
Do I understand correctly that Snapcast client can play audio directly from Mopidy ? And how to choose the server ? If not from Mopidy then some other UI is needed anyway.
You set Mopidy to output to a named pipe, instead of the soundcard. Then Snapserver serves the audio, allowing any Snapclient to listen to it. If you run Snapclient on the same box, you can get it to play it’s own audio, like if you were just using Mopidy by itself.
Snapcast has an app that lets you control the clients and which server they are listening to. You can certainly control the clients connected to a single server. I’m not sure how well it lets you switch a client between multiple servers.
The issue is that you’d have your mpd/web client UI to control Mopidy and then have some other separate UI to control the snapclient. So it’s a slightly more clunky experience in that respect, but better in other ways.
I suppose this depends on the specific needs/use cases. Generally one UI does not suffice because there will be always need for a central UI to configure the multiroom setup (which device listens to which source), of course one could do it with only Mopidy by iterating over all Mopidy devices and setting desired source, but this is very clunky. For this I use OpenHAB, because I already use it for other stuff in my home, the Snapcast is another way of doing it.
Yes it’s clear to me now that you are very right. With an OpenHAB setup is there one master device that you connect to and everything else is a slave or is it more complicated than that?
I have one master device. So only one “zone” is possible. With my solution (I mean the rtsp synchronous streaming + OpenHAB) it is possible to make all devices act as master device - so multiple zones, but then the OpenHAB part would need a lot of work to support multiple zones.
I tried this last evening, but couldn’t sort it out properly. Do you have any more info on setup?
How far did you get? You need to:
- Set up Mopify
- Install Snapserver
- Install Snapclient (as above)
- Redirect audio output from Mopidy to Snapserver
- Direct Snapclient output to soundcard
I can’t find the docs for this at the moment, but you have to find out the ID of your soundcard.
snapclient -l will list them all, I think. Then you add a parameter in the snapclient config file to tell it the ID.
Thanks for your reply, I have set up from 1-4 last weekend and it all worked fine. However to change from a single instance to multi room I am currently using LIRC to control it. It seems your method would be preferable but I can’t figure out how to do it. When I tried last night I could only find one snapserver at a time, (not multiple snapservers) and each of those only connected to the client on that actual pi and to the app on the phone.
It could be that it needs number 5 from list to identify each server on the app. I’ll try later.
Ah, right. I haven’t actually got it working with a single client switching between multiple servers yet.
That’s the next job.
I think it should be possible, but I don’t know if there’s any kind of UI to make it easy to do.
It looks like one of the options for
snapclient lets you select the server it should connect to. You could potentially modify your LIRC script to to restart the client using a different server until there’s a better solution?
I was hoping to get away from having to remember the remote, so probably won’t gain much from modifying the LIRC script, it’s already working as is, although a bit clunky!!
I’ll keep an eye out for any ongoing changes though.
Let me know if you find a good way to do it. I just haven’t spent much time looking into it yet.
I’ve been playing with Snapcast and am now using wired Pi3B as Snapserver & client, and wired Pi B+ and wireless Pi Zero W as Snapclients, it’s working almost flawlessly, with very few (if any) gaps.
On the Pi B+ I am also running Mopidy as a user (not as service) this appears to allow the both Mopidy and Snapclient to share the audio card, so just pausing one I can listen to the other.
Although it works well and overcomes the problem of switching to play different music in different rooms, I don’t think it’s the proper solution and would be interested to hear of any reasons this set up might cause problems.
Thanks for the update. I’m just using a Pi2B as the client/server, which is working fine. I haven’t been using any separate clients though, other than the Snapcast app itself.