I’ve been looking for a good replacement for my current Logitech Media Server setup.
Priorities are:
Spotify support
Modern UI
Sync/bridge mode (multi-room)
Open standards
Mopidy seemed to be the solution, except for the sync mode.
I have several pi’s acting as clients with a dedicated DAC connected to my multi-channel amplifier.
I’d like to be able to stream the same music from one server to several rooms (in sync) or having different streams playing in different rooms.
LMS supports this but has a terrible UI and requires registration at Logitech.
Whenever Logitech decides to drop the support, it’s over.
Are there any workarounds or plans for sync support?
That would be a killer feature!
Thanks!
Edit:
To clarify:
Since Spotify only supports 1 simultaneous stream,
I’m looking for a solution that can
broadcast that single stream to multiple rooms or
play 1 spotify stream and 1 (or more) other streams (e.g. local mp3’s) to multiple rooms
I know Wouter has been working on some workarounds for this in musicbox itself, and I know we (Mopidy developers) have also had something like this in our sights for a while…
The most immediate solution is to setup the output of mopidy to be a multicast stream and then have gstreamer running to pick it up on the clients. This would work but isn’t to elegant as you have no control as it becomes all or nothing. Though the latency shouldn’t be to bad this way. Can dig up some more details on how to do this, but it’s all very experimental.
For the longer term we have quite a few things in the works which should make this truly useful:
Fixing up the audio handling so track changes don’t break streams.
Adding our own HTTP streaming as an alternative.
Adding support for a “service discovery”, this is initially trying to add the infrastructure to allow for BT speakers etc, but would also work for a multiroom the way things are planed.
Re-adding multiple output support once we have GStreamer 1.x instead of 0.10.x
Possibly adding a GStreamer network clock, this would allow for better synchronization taking network delay into account (won’t fix the song changes being slow)
The even further future for this could be then having mopidy, or a mopidy thin client running in each room and tying into all of the above. And if we assume mopidy based code on both ends we could probably also have a control channel where we notify them to flush the buffers on song changes for nicer handling of track changes.
As for multiple streams, for now we are likely just sticking to having a single stream all over given the limitation Spotify imposes.
All in all this is still quite a while out, but we are working on the incremental improvements to hopefully become an awesome multiroom streaming solution. Many of these outstanding items are still orthogonal, so any one interested in working on some part of this should get in touch and we can point you in the right direction
All right, thanks for the answers.
I’ll have some trial (and especially) error sessions in the coming days/weeks
I’ll try to remember posting it here once I’ve got a working solution.
Are there any news about these special features? It sounds very interesting.
One year ago i have a multiroom solution like this:
1x LinuxServer in my technicroom with MPD and two pulseaudio outputs in /etc/mpd.conf
audio_output {
type “pulse”
name “Kitchen”
server “192.168.1.19”
}
audio_output {
type “pulse”
name “LivingRoom”
server “192.168.1.12”
}
1x RasPi in my Kitchen as Pulseaudio Client
1x RasPi in my LivingRoom as Pulseaudio Client
It worked but it never was synchron. So i searched for an alternative and tried something else with mopidy. I found this thread an iam very interested for this features. Are there any news of this ingenious project?
I suggest to use SnapCast for sync multi-room audio playback.
It’s simply a synchronous audio forwarder that can be used with Mopidy: SnapCast mopidy setup.
There is one SnapServer running on the same machine as Mopidy, reading audio from a GStreamer filesink. All SnapCast clients in your network will sync their time against the server and synchronously play the audio.
I built a multiroom system with rasperry pi + audio8dj (you can use a different card) + 2x mopidy service (maybe even more).
Mopidy start as a service.
I copied and I created another service “mopidy2” with another configuration file.
I use mobile extenssion.
Two mobile extension run on difrent port (the first is room and kitchen is 2).
Of course, you need two amplifier. Or one multichanel.
I use one account spotify and local shares.
For now everything works without problems.
It seems that SnapCast is not useable on my PiMusicBox ver. 0.6.
I tried installing snapserver_0.10.0_armhf.deb but there is a dependency of libflac8 (>= 1.3.0) but unfortunately wheezy has lower version, libflac8:armhf on system is 1.2.1-6+deb7u1 installed and i could not find a solution how to install libflac8 1.3.x.
Is anybody aware how to solve?
I forget at which point I gave up on PiMusicBox and went to straight up Raspbian Jessie/Jessie Lite with MusicBox, Mopidy, SnapCast. I can only say that it went a lot more smoothly once I did. I have eight nodes set up at this point. It works with relatively few dropouts. The server has a USB3/Gb ethernet wired adapter (it’s significantly faster than the built in) and the nodes are either wired or have an Edimax EW-7722UTn adpter (the little Edimax nubs on the old Pi B’s were a bad combination, lots of dropouts, I think its the better antennae on the bigger one that made the difference).
Although I got quick out-of-box experience with PiMusicBox and it was a good proof of concept, I soon felt like it was fighting me. I highly recommend at this point that you pick up another SD card and try to roll your own from scratch. I got it the first time in a weekend and now that I have notes I can easily build one up from scratch in a day.
I’m glad it’s working. I think my biggest issue with drop outs was that the original PiB’s (half of my eight nodes) are single core. From what I read, the USB port is pretty CPU intensive to the Pi and the PiB’s are single core so they’d have drop outs. I think the Edimax I referred to above has fewer dropped packets due to a better antennae than the little Edimax nub that most people use. All I can say is that replacing the WiFi adapters dropped right in with no additional configuration, pretty much eliminated the dropouts and cost a lot less than replacing the four PiB’s with Pi3’s.
I think it also helps that the SnapServer is a Pi3 with a fast (relative to other Pi’s) wired connection so it can receive streams and pipe the output fairly efficiently. I experimented with using different formats in SnapCast (it will do its streaming in Ogg, FLAC or Wav) and the default (FLAC) gave me the best performance.
Lastly, in terms of efficient maintenance and general listening environment, I’ve found it best to have the media on a thumb drive so I can have a fairly large drive for the library, easily change the contents from a PC and also effectively backup and manage the SD card on the Pi, which can be much, much smaller. The server used to also host my NAS and the big mechanical drive was distracting. I also tried a large SD card, but backups with my Windows machine were prohibitive due to the bitwise copy and managing the library entailed jumping through a few hoops.
I am aware this topic is almost 2 years old. I too was experiencing dropouts with snapcast. I was not able to fix it in snapcast itself but created another project that has the same goal.
With snapcastc - a C reimplementation of snapcast, I am able to play audio without dropouts on simultaneously on multiple raspi B with improved latency behavior.
The api is not completely implemented yet but muting/unmuting and setting volume works already.
How far along is the C version? I need to figure out how to make SnapCast work with groups and multiple servers. C is very familiar to me, although I also want to learn Python much better. My house is set up such that I should be able to have a multi-user solution without any configuration changes, but the usage via either the Android app or Mopidy Iris confounds me. I did manage to get it back to all clients playing back the primary stream, which is good enough for now.
Is there anything at all that documents how to actually use SnapCast with multiple servers/groups? I feel like I’m missing a HUGE part of the plot.
