[jrubenol]

I'm sure this has been discussed before but I'm going to bring it up again - I've found some third party stuff such as http://forum.xbmc.org/showthread.php?tid=134943 but it doesn't work well at all with the raspberry pi and requires LMS which I think is a bit over the top for something as simple (apparently...?) as making two device play the same song at the same time.

For anyone who has multiple xbmc setups - which seems to be quite a few as there are instructions and substantial development time dedicated to complex syncing through sql for library and what not - we can assume that many of us have multi room setups using xbmc.

For any serious audiophiles who have multiple room 5.1 (or even 7.1 setups), having a multi-room synced playback would be amazing - even more so if we could name distinct computers as "bedroom" "living room" "backyard" and then turn them on/off as needed/desired.

So my question is, in development terms, why is this complicated? If you have a synced library over NFS or Samba - playing the same file seems very easy just from a novice speaking - and yes I know I may get the "then go develop it yourself". I'm really quite curious what is hard about this as I have no (or very limited) programming ability.

Since audio files are so small, you can stream really seamlessly songs over NFS (and I presume samba, although I don't have that setup) - making them stream at the same time seems relatively straight forward.

Just my two cents, I love the product and am very happy with virtually everything about it, beauty of open source is that we can pool ideas and cross our fingers that brilliant devs will accept a challenge and add new features


Best,
Joel

[ppic]

you're right on one point:

playing the same file seems very easy just from a novice speaking

[Memphiz]

You assume that each player would play an mp3 with the same speed. Just try it with one of those 8 min metallica songs and tell me if they will end at the same time when started together on 2 different systems.

[337Manni]

This would be an amazing feature though!

Had a bbq the other week and found myself having to pick between the living room or conservatory PC to play music. Would have been great to have both playing the same.

[jrubenol]

hm, Memphiz - they don't play at same speed? that's mind boggling I thought 8 minutes was 8 minutes Good choice of bands though, one of my favorites :-D

@337Manni - check out the link I posted - unless you are using a Raspberry Pi, it works quite well - thus making me think the time issue isn't that big of a deal

What about doing a check every second to verify at same point, if not, faster machine slows down slightly. Dunno, is this an insurmountable holdup?

[Memphiz]

Well just readup the reverse engineered AirTunes protocol from Apple. I bet there is a reason why they do that complicate per packet sync policy. What i wanted to say - its not done by just starting the playback at the same time - and so it is not that easy as you might think.

[jrubenol]

I'm tempted to put this theory to the test - same playlist, 5 hours long. Play both (muted of course ) on two separate machines off of shared library over NFS. I'll check every hour to see if the songs are (for all relevant purposes) at the same point....might give some interesting results

[QLink]

would also love to use xbmc for multiroom audio with rasberry pi...

[337Manni]

Must have missed the link the first time... thanks. Had a read of the first post and it sounds promising. Will have to give this a go!

[bry]

you can use VLC for this - http://www.youtube.com/watch?v=kvqIYEFy21I if xbmc is not an option for the time being.

[topfs2]

There is quite a lot of complications regarding this. I've spent quite some time developing such a system, mostly as a trial to see how it behaves.
Try yourself to try and press play on two machines at the same time and see if you get them to sync. Even if you press exactly at the same time the two machines will take different amount of time to initiate playback, and even if that takes the same time it may take different time for the packet to go from xbmc to the speaker.
And if you consider the case where you have two machines where one has started already you need to deduce what the clock is actually on the other machine, while trying to deduce how long it will take the packets reaching the other machine.
And you need to handle if one machine starts messing up playback, how much should you fix it for them to be correct.

And you need to do all this so that the clocks aren't wrong more than 10ms, and consider that when you play game you quite often have ping of 10ms, so in essence, the time it takes for the packet to go from you and back (which is the uncertainty) is enough to make it out of sync.

In the end I've found that most of these can be overcome, but it takes quite a bit of care when designing the player. Which is what I've done on my own testing, I had to redesign it 3-4 times to get it right. And that one still only really work on linux and no other platform

[Memphiz]

But it really can't be that hard [tm] - thx topfs2 for backing my theory.

[QLink]

Which is what I've done on my own testing, I had to redesign it 3-4 times to get it right. And that one still only really work on linux and no other platform

so you have developed something working right ?
will your system work with openelec ?
and more important will it work with openelec on rasberry pi ? (no working alsa on openelec @pi)

best greetz

[whitebelly]

This would be a nice feature for video as well. (although I suppose it is improbable for the same reasons as audio). 2 use cases include multi-unit car video players (allow passengers to watch the same movie, or different ones), and display kiosks.

[topfs2]

Which is what I've done on my own testing, I had to redesign it 3-4 times to get it right. And that one still only really work on linux and no other platform

so you have developed something working right ?
will your system work with openelec ?
and more important will it work with openelec on rasberry pi ? (no working alsa on openelec @pi)

best greetz

way to quote the single part of my explanation you liked and completely skipped all the other negative stuff

I've spent quite some time developing such a system, mostly as a trial to see how it behaves.

I did not code it for xbmc and I didn't make it with xbmc in mind. It was a personal test and I just wanted to share my knowledge on the matter.