> > mikeb Wrote: >> 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. > > Personally, that's not a route I would prefer. > > Assuming the drift of the timebase (crystal?) in the squeezeboxen is > fairly low but there is some individual variation amongst them, a > better correction would be, at startup time, establish error in the > crystal and correct for it low in the timing chain. > > Dropping frames, as you propose, would be audible. Correcting the clock > errors could be done much more fine-grained. > > Michael > >
either would be a vast improvement over the current situation though. I tend to prefer the idea of dropping frames because I don't assume that the clock is the only source of error. In fact, if I had to guess what causes the synchronization issues that are seen now, I'd blame the TCP stack. Anyway, as others have noted, multicast doesn't like wireless. -- Jack At Monkeynoodle.Org: It's A Scientific Venture... "Believe what you're told; there'd be chaos if everyone thought for themselves." -- Top Dog hotdog stand, Berkeley, CA _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
