a few things...
first off, you guys are in the wrong thread. this is about my ajax music browser. please take your fight elsewhere.
now lets get a few things straightened out. ajax and synced playback have absolutely nothing to do with each other. the only slight connection is that ajax might be the technology to use to have control over all of the players in a nice web based gui.
the actual synced playback is much more involved than ajax. i've talked with other devs and users about this and decided to try it myself to see if it would work. basically i was trying to send the play command to all units at the same time to see if they would sync up. they all play staggered with about a .5 second delay.
since some info about my new project has already leaked, i thought i'd throw this out there to give you an idea on what's in the works. this little app will allow you to monitor all xbmc players on your network, see what they are playing, or launch into the web based music browser of a particular player. eventually i hope to include every http api command to be made available from this program for absolute control over any number of xbmc players on a network.
it can scan the network for players, and when it finds them it adds them to the list.
then it will allow you to check the boxes next to players you want to control and send an httpapi command to all of them at the same time.
to answer the initial questions:
yes, this is real and most of what you see above already works
no, you can't have it yet
no, when i check off all xbmc devices and press start playing they do not all play the same audio at the same time.
yes, i will release it to the community when it's ready to be released.
that's all you get for now!
hifty: check back often for updates on xbmc distributed.
---
now...
the only place i have seen synced playback work well is in slim devices' slimserver gear. they have a special buffer chip which allows them to buffer a certain amount of audio then have the server send them all a cue on when to start playback.
here is a snippet from their api docs:
Quote:streaming and buffering
the slimp3's buffer chip is a 128k x 8 (1mbit) sram. it is presented to the server as a 64k x 16 circular buffer. the server sends packets to the client, with the address in the buffer where they are to be stored, and with a sequence identifier. the client acks each packet as it receives it. the server ensures that each packet has been acknowledged by the client, and will resend any packets that are not acknowledged promptly. once the server has filled the client's buffer it will send zero length data packets, and will monitor the read pointer returned in the client's acknowledgment, sending further packets as necessary to keep the buffer full.
the read pointer is maintained by the client, and is the position from which the decoder is currently reading. the server can order this read pointer to be reset to the beginning of the buffer by sending a control code of "3" to the client in a data packet. these control codes also control whether the decoder is running or not (see 'm' write mpeg data).
at the start of each track, the server will send a number of packets with the control set to "3", in order to allow the client to build up a small buffer before starting decoding. the control with then switch to "0". "1" is used to pause the player.
the slimp3's buffer chip is a 128k x 8 (1mbit) sram. it is presented to the server as a 64k x 16 circular buffer. the slimp3 maintains two pointers, called rptr and wptr, which track the position at which the dma controller is reading (out to the decoder) and writing (in from the network). when a new stream is started, the slimp3 begins by initializing an empty buffer, with rptr == wptr == 0. it then begins requesting data from the server, starting from 0. the server replies with some data, which the slimp3 writes into the buffer. once the buffer reaches 50% capacity, the decoder is started, and the rptr begins to increment. the slimp3 continues requesting data until the buffer is 90% full. once the buffer reaches this "almost full" state, the slimp3 continually checks buffer usage, requesting more data only when the buffer usage drops below the "almost full" level.
timeouts due to a lost packet are handled by the client. it the slimp3 does not receive a response from the server after 100ms, then it sends the request again.
now this assumes you have an actual server streaming to all of the clients. in their case the slimserver is feeding all of the 'dumb' clients with the audio data and they just play when they are told. in our case it would be more like having an smb share with your media and having all of the xbmc units intelligently communicate with each other to tell which songs to sync, buffer a song and all at the same time press 'play'.
so my idea to get this working ... is that code needs to be written into xbmc which allows one xbox to communicate to the httpapi or a socket server of another xbox. then some new commands would need to be added to tell the xbox to queue up a song into a buffer but keep it paused. and another countdown type command where one xbox starts the countdown via a socket connection to another xbox?? and they all countdown togther to 0 and start playing.
there are probably better ways to do this and i'd like to see some discussion on how this can be achieved in the appropriate threads.
