inline.
Michaelwagner wrote:
I am sure I only understand some of the issues involved, but the problem
is complex.
At the moment, synchronization occurs at every new song.
The various squeezeboxen (which can be of different generations) all
buffer up and wait for a "go" signal. The go signal is probably sent
multicast, but I actually don't know that for sure. After the go
The signal is sent unicast to each client. No multicast traffic is
being generated.
signal, they all buffer and stream out music to the end of the song,
then all buffer up and wait for the next song to start.
Within one song, they rely on the accuracy of their own clocks to keep
in sync with each other.
In the software roadmap
http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap
there is a line item for using a network clock for synchronization. I'm
not sure what implementation that would take and whether multicast would
play a role, but it seems a likely route. The goal, though, would not be
to multicast the content (which is very difficult when sending to
multiple generations with different buffering and streaming
requirements) but merely to multicast a synchronization clock.
Even still, I don't know what accuracy you can get with multicast.
Across a hub, propegation is essentially instantaneous.
Across a switch, there is a very tiny delay and the potential of a
longer one if there is interfering traffic on the other side of the
switch. I don't know if there is a promise by the protocol to limit the
delay to a level where it would be insignificant for this use.
Across a wireless access point? I expect all bets are off. I'm not sure
multicast will offer any advantages there ...
As you've said, the benefit in multicast to the multiple client
synchronization would be minimal (if nonexistent). The benefit to
multicast would be lower bandwidth utilization in a situation where
many clients exist. A heart-beat sent to the server by each client
with a frame number and ntp time synched time stamp would allow the
server to send a signal to the client to advance the track 3 frames to
catch up with the other clients. Of course, if there are only two
players there would need to be logic in the server to decide who was
more accurate on a consistent basis. If done every second, the effect
would be near perfect synchronization. From reading about Sonos, this
network heartbeat is how they synchronize accurately.
Multicast could be used to send the heartbeat to a group address, but
since the logic needs to be controlled at a central location (if 4 of
your squeezeboxes all decide the one fast is the most accurate you get
degraded sound on 4 instead of 1, there needs to be central control of
the logic), it makes the most sense to only unicast it to the server.
This continues to follow the client/server model Slim Devices has
incorporated to date as well.
Now, for the actual music stream, I send 192k VBR MP3 to the
squeezeboxes in my house. I can imagine the remote possibility of say
7 of them, and on a high bitrate song, that comes out at about
1.8mbit. My 54mbit network is hardly going to even hiccup at that.
Personally I prefer the rudimentary network capabilities of a unicast
network that would allow me to easily setup remote routed nodes for my
squeezeboxes, be it either in the house or over the Internet. Keep in
mind I also work on a few hundred node network using Multicast in
multiple capacities for a living, and I don't want Multicast because
of it's complexities, watch out for your standard user..
My suggestion for anything with a HUGE number of squeezeboxes is the
development of a method to bounce streams off another slimserver, so
that 30 squeezeboxes on floors 1 and 2 of the hotel can be on
slimserver 1, and the 30 squeezeboxes on floors 3 and 4 can be on the
second one. While both slimservers synchronize themselves in the
background. But even with 60 squeezeboxes running at 256kbit, you're
still only talking 15mbit. Find APs, switches, and routers that can
understand 802.1p QoS and set the priorities accordingly so you can
differentiate your music over the web browsing on the network and you
should be good.
Hell, with 60 rooms and a 100mbit network you could have every room
listen to music, talk on a VoIP phone, and browse the web with very
little degradation to their web surfing, and absolutely none to their
phone calls and music if CoS is enabled properly.. Since not every
room will do everything at the same time, a cheap 100mbit switched
network could provide the entertainment and communications for a 60
room hotel.. pretty impressive.
Now, if you're scaling a setup with 100s of squeezeboxes I would
suggest you talk to Slim Devices before going forward, I bet they
could dedicate some development time to figuring out how to meet your
needs =) (hey, money talks right?). If Multicast is the only answer,
they may be able to do it in the squeezebox firmware, but just be sure
to leave the rest of us our simple unicast world!
-- Mike
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
