Mopidy: Multi unit synchronous audio

[lydhig]

I would like to use several (in my case Raspberry Pi with Pi Musicbox) in my house. I would like to have all these units play the same stream synchronously. This means that I could play the same Spotify music in all house with one Spotify account. To make this all audiobuffer in all units has to be synchronized with each other.

The expensive audiosystem Sonos has this killer feature.

[adamcik]

http://gstconf.ubicast.tv/videos/multiroom-playout-home-area-entertainment/ and http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/gstreamer-conf-2012-schmidt-aurena-presentation.pdf are relevant watching/reading for a developer wanting to implement this.

Basic idea is we have a custom gstreamer element with a network clock and output to say a local multicast group. This should be combined with a client that gets data from multicast and uses our network clock for sync. If this is created we would have the minimum set of pieces for this to work. More fancy things like control of each client/room would be the next phase.

[adamcik]

Setting the output to tcpserversink host=0.0.0.0 port=6690 protocol=gdp and using gst-launch-0.10 tcpclientsrc host=$MOPIDYHOST port=6690 protocol=gdp ! autoaudiosrc on your client is a start, but track changes etc will wreak havoc on this setup with the current state of mopidy (and I doubt the zones/rooms would be in sync).

[adamcik]

http://lists.freedesktop.org/archives/gstreamer-devel/2012-August/037116.html

[bronco21016]

adamcik,

I've been searching around to find this killer feature in a Linux package and this is the only place I can even find a mention of it.

Was this implemented? Or was it closed because it was deemed unnecessary or not wanted?

Thanks for the awesome package!

[adamcik]

It's still on the roadmap (http://goo.gl/Bs6uua) just far enough out that this isn't a direct priority yet. Also we might end up making it an extension depending on how things actually get solved.

So still something I want to do, something I mostly know how to do, but it would take more time than I have to give it right now as the devil is in the details :-)

[kingosticks]

I remember seeing a few posts on the raspberry pi forums about this kind of
thing. Maybe you'll find this helpful:
http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=25684&start=25
On 8 Apr 2014 19:29, "Thomas Adamcik" [email protected] wrote:

It's still on the roadmap (http://goo.gl/Bs6uua) just far enough out that
this isn't a direct priority yet. Also we might end up making it an
extension depending on how things actually get solved.

So still something I want to do, something I mostly know how to do, but it
would take more time than I have to give it right now as the devil is in
the details :-)

Reply to this email directly or view it on GitHubhttps://github.com/mopidy/mopidy/issues/408#issuecomment-39884244
.

[SeanDS]

I've been looking at making a Sonos-like system too recently, and I've decided that the solutions involving Logitech Media Server are a bit clunky (in particular I don't like Perl). It looks like Mopidy would do a great job of getting the music locally and from Spotify, so the remaining problem is getting the synchronised streaming to work.

It seems the best way is to use RTP (Real-time transport protocol) somehow. I've not got any experience with this - can anyone tell me if this is already a feature of e.g. PulseAudio or is it something that needs programmed in separately, in terms of Mopidy?

I don't know if it's necessary to play about with sending multicast messages to the local network for this kind of synchronised play. If the system is truly Sonos-like, it will have to handle separate audio streams being sent over the network as well as identical, synchronised streams.

Anyway, I would be willing to try to solve this problem. I'll maybe start to play around with Mopidy when I next have time.

[kingosticks]

I meant to ignore the LMS stuff and focus on the pulseaudio info within
that link. There's even an example using mpd which I think will answer your
question.

And https://github.com/thaytan/arena seems to be going about it the other way, with additional gstreamer application code rather than pulse.

On 14 Apr 2014 00:24, "SeanDS" [email protected] wrote:

I've been looking at making a Sonos-like system too recently, and I've
decided that the solutions involving Logitech Media Server are a bit clunky
(in particular I don't like Perl). It looks like Mopidy would do a great
job of getting the music locally and from Spotify, so the remaining problem
is getting the synchronised streaming to work.

It seems the best way is to use RTP (Real-time transport protocol)
somehow. I've not got any experience with this - can anyone tell me if this
is already a feature of e.g. PulseAudio or is it something that needs
programmed in separately, in terms of Mopidy?

I don't know if it's necessary to play about with sending multicast
messages to the local network for this kind of synchronised play. If the
system is truly Sonos-like, it will have to handle separate audio streams
being sent over the network as well as identical, synchronised streams.

Anyway, I would be willing to try to solve this problem. I'll maybe start
to play around with Mopidy when I next have time.

—
Reply to this email directly or view it on GitHubhttps://github.com/mopidy/mopidy/issues/408#issuecomment-40323518
.

[SeanDS]

Ah, that's helpful, thanks.

I also noticed this: http://fruit.je/mpd-rtp. It appears to use RTP and MPD. It should be possible to crowbar Mopidy in there somewhere to get Spotify access...

[kingosticks]

Yep, that's the example I was referring to. I think you might want to keep in mind that at some point mopidy will move to GStreamer 1.0 with PyGI (#225) and mopidy's gstreamer stuff will have to change. You should be aware there's no guarantee the same functionality is exposed through PyGI, something worth checking before you invest a load of time in it. If you focused on a purely pulseaudio solution then you'd be immune to that. Additionally, the performance of PyGI might even make doing this infeasible to do in python - I'm just guessing here.

[SeanDS]

Cheers for the info. I'm not so familiar with the way Mopidy works - I only found it yesterday when I had the idea to make a Sonos-like system.

Does Mopidy use GStreamer to produce streams that devices can access over the network? Or is that not what GStreamer does? I only mentioned PulseAudio above as an example - I don't know if Mopidy uses it or not.

Anyway, since I don't really know how Mopidy works I will first set up a single Raspberry Pi and try to stream stuff from Spotify via a home server. Then I guess it's a case of playing around with Mopidy's configuration to get it to use RTP and stream to multiple devices?

[kingosticks]

Gstreamer is a multimedia framework. The output of which is dependent on how you configure the pipeline, it could be a network stream but it's usually your local soundcard. For mopidy it can be configured using the audio/output setting. Also see advanced-configurations. Take a look at the gstreamer and pulseaudio wikipedia pages and docs for a better overview.

But anyway, do get mopidy setup and get stuck in. The mopidy documentation is great and @adamcik's info above looks very useful.

[SeanDS]

Thanks for all of your help. I'll give this a go!

[SeanDS]

I've been looking into getting this stuff working and I'm not sure how the configuration exactly works with [audio]/[output]. If I've created a custom PulseAudio sink, do I specify it here, or do I have to use 'pulsesink' and set the name of the sink somewhere else in the configuration?

For comparison, this is how a pure MPD server would specifiy such a sink, in /etc/mpd.conf:

audio_output {
    type            "pulse"
    name            "MPD Stream"
    sink            "mycustomrtpstream"
    description     "what's playing on the stereo"
    mixer_type      "software"
}

Aside: is there somewhere better to post questions like this? I can't find a forum...

[jodal]

You can run the command gst-inspect-0.10 pulsesink to view the properties you can adjust when using pulsesink. For example, it lists the properties device and device-name for setting the PulseAudio sink and its human readable name.

You can then set GStreamer element properties in mopidy.conf:

[audio]
output = pulsesink device=mycustomrtpstream

There's no web forum for Mopidy, but we have the [email protected] mailing list which you may use.

[SeanDS]

Thanks, I've got it to work now using that method. I've got PulseAudio set up to multicast an RTP stream to my network, and I've got a Raspberry Pi tuned in to listen to it.

What do you have in mind for this kind of feature in Mopidy? Is the idea to avoid having to use PulseAudio altogether?

[felixb]

Btw: I'm able to play audio streams from my notebook to a set of raspberries.
There is no multicast involved at the moment. The multiudpsink is working quite well.
I could not here any gabs between the ouputs.

There is no modipy involved yet. But I'm planing to hack something.

It's not stable and sometimes, it just don't work. But it's a start.
https://github.com/felixb/audiofrk

[sashahilton00]

Just reopening this thread as there appears to be a solution that could be easily bundled with mopidy and would make a killer feature:https://github.com/badaix/snapcast is a separate service that accepts any audio piped into /tmp/snapfifo and then broadcasts it in sync to any clients that are listening for it. It doesn't enable individual music on a per room basis, but it does enable synced multi-room audio, and would be a good place to start if thinking about multi session audio streaming, though managing multiple streams isn't possible with a single instance of mpd/mopidy yet I think... perhaps mopidy could later add functionality to manage multiple mpd instances, then multi session streaming would be possible...

[SeanDS]

Ah, that's very exciting! It looks like there are even instructions for Mopidy. Thanks for the update.

[linuxguy123]

I'm very interested in this as well. I'm willing to write some code or test.

[sashahilton00]

It would be great. Sadly I just put it on here for informational purposes, and am far too busy to be contributing anything significant. Works well when testing though :)