Multizone Mopidy - multiple instances on a server , multiple USB devices

General
1

I want to set up a multi zone system using mopidy.

I’m willing to do some coding to get it working.

I’m thinking the best architecture for doing multi zone with mopidy is to have a single server running multiple instances of mopidy (1 per user?) and have 1 USB sound device per zone. In my case I would have 3-4 users (mopidy instances) and 12 USB output devices.

For a user to direct sound from their mopidy instance to a zone or zones, they will have to be able to select the output device in the client. Where does one find the mpd spec and does it support the client being able to select the output device ? Do any mpd clients support this functionality ?

If all the USB devices are on the server and a single mopidy process is feeding the USB devices the feed multiple zones, would one need to further synchronize the waveforms between zones or would they be close enough ? I assume the “feeding” would occur in the alsa or pulseaudio layer. In my case I would have a dozen USB devices, any or all of which could be “played to” at once.

Any thoughts on implementing this, first in the mopidy code and later in the web client and then in other mpd clients ?

There are other ways to do this, but I’d like to discuss this one first and see where it goes.

2

No comments on this ?

3

We have previously tried doing multiple outputs to get closer to supporting this type of idea. However at the time we still had just GStreamer 0.10 and a number of other issues, so we rolled back the changes.

There is also https://github.com/mopidy/mopidy/issues/1118 which was submitted more with BT devices coming and going in mind, but for me this just as well would support mopidy being and output for mopidy.

So basically I would like to add a concept of an Output that extension can provide. Which then could be used to build a mopidy-mopidy extension allowing mopidy to sync to an other instance. Ideally we would use something like zeroconf to do self discovery.

Ideally we also add GStreamer’s network clock into the mix allowing less skew between zones.

So yes I’ve thought quite a bit about this, but the list of things that have needed solving before getting to looking at this has just been to long. Hence this halfway brain dump of a followup :slight_smile: