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 