Synchronize media playing in multiple rooms?

[Dale_K]

When I use the floorplan to play music simultaneously in multiple rooms they are not synchronized.  Is there a way to sync them?

[golgoj4]

Currently, no there isnt. Basically, its a timing issue and if you search you can find a more in depth explanation of whats actually going on.

[bulek]

Maybe it will work with squeeze HW players and squeezeslave as SW counterpart...

Regards,

Bulek.

[tschak909]

the fundamental problems in a nutshell:

* IP is not isochronous by nature. Try as you might, perfect sync isn't possible without layer 2 changes.
* The Squeeze players are further exacabated because they do not emit time code back to Orbiter, and therefore can't take advantage of the necessary time code functions.
* Differing protocols which necessecitate different stream types. This was done in order to support heterogeneous mixtures of different devices and have things PLAY at the end point, however, especially when you're sending a mediahandler stream to different plugins to marshal out to different players, the stream gets split, each with its own StreamID, handles, etc within the media plugin.

Multi-zone amplifiers basically side-step all this by taking the "phone system" approach to distributing everything..everything gets its own dedicated wires, and it's switched in this manner...LMCE supports multi-zoned amplifiers as well....

The solutions on an IP level will have to be clever, especially if we want to maintain the heterogeneous off the shelf flexibility we currently have.

-Thom

[hari]

you can "link" 2 squeezeboxes from the squeezecenter.

br, Hari

[tschak909]

Then, we'll need to add that functionality into the Slim Server Streamer.

We also need to give the Slim Server Streamer a Time Code port, and thread, and have it report back the time code from the Squeezeboxes in Orbiter Time Code format.

-Thom

[colinjones]

Thom - btw, can't remember if I reported this back. I said I was going to have a quick look at what the squeeze protocol allows by simply telnetting into the port and seeing if info about button presses are reported back. Particularly this was related to not being able to forward/reverse through LMCE playlists. The squeeze boxes just treat it as a single entry playlist until the media(plugin?) tells it to play the next track.

I found that you can subscribe to events quiet easily after connecting to the squeezecenter. After that it pushes text events back to you on the telnet session reporting track forward/reverse/volup/down/etc that the user presses on the squeezebox. So it is certainly possible to integrate more bidirectionality in the squeeze streamer plugin so that LMCE knows to jump to the next track, volume up down etc. But that is where my abilities run out. From there I would have to get into the streamer code, and that is beyond me presently. I didn't look for the time codes (I know Xine reports these back for sync), are you sure there isn't an option for this in the squeeze protocol?

Alternatively, perhaps the functionality can be backed into squeeze by instead of relying on center proactively pushing timestamps back, mod the streamer to poll for position from center and simulate the timestamps being sent by sending them from the streamer instead. Again, not sure that the squeeze protocol supports this but it is more likely than the alternative. Especially, because I'm pretty sure that the center web interface allows you to resume a track, so either the squeezebox simply remembers the resume point itself (which wouldn't help us!) or center knows how to query the current location when the track stops, and how to jump back to that location for resume (which would mean we could hook into whatever protocol commands it uses for that) Maybe?

[tschak909]

For timecode...

Basically, All Orbiter cares about, is that a given media player has a port that it exposes.

For Xine_Player, this is port 12000. Play a movie, connect to a media director's IP, port 12000, while this happens...

you'll get back a comma delimited set of values, that updates, once each second. Orbiter deals with this directly, and every single orbiter in the house connects to the media player port. This port is specified in the device data of the media player device, (DEVICEDATA_Port_CONST), and should be adhered to, because Orbiter uses this value directly. The timecode should be dealt with in its own thread, doing any synchronization as needed back with the main command thread.

-Thom

[colinjones]

So the only way this functionality could be added is if the streamer plugin were extended, 1) to periodically (every second) query the SqueezeCenter software for a time stamp, 2) add a similar port in its device data and select a port number default, and 3) start listening on the port specified in that device data field, and should a TCP connection come in, start pushing the queried timestamps out?

From your explanation this would only provide timestamping for sync, not other control like track forward/back and vol up/down - presumably that would have to be implemented in the streamer plugin through conventional DCE messaging?

[tschak909]

Yup, pretty much, the slim server streamer would have to send back events that things had changed.

-Thom