Hari,
The original problem? If you mean break up in playback because of variable latency/bandwidth then I would agree with you. But I believe we are talking about the sync issue... if so, then no, buffers are the main cause of this issue on a local segment! The fact that you are using a buffer, that fills and empties on demand as bandwidth/latency varies means that you can never get an exact sync because there is no correlation between when the packet data arrives and when it actually gets played - it depends as much on the size of the buffer, how long the playback mechanism waits before playing back, etc. That can easily all vary between playback devices causing a loss of sync....
I agree that IP is not ideal nor guaranteed over routed subnets (particularly the Internet), but on a local switched segment, a buffer is not needed to deal with variable latency (by which I mean a large buffer, the playback device will always have like a tx-ring type, tiny fifo to queue) as the latency on a local switched segment is tiny and hardly varies at all until the interface is already congested - at which point playback would fail for any technology.
What I'm trying to say is, I agree a buffer is absolutely required on routed streams over distance, without which the stream will stutter, fart, crap out, etc. But on a local segment, the steam can be made to work reliably without a buffer, and the buffer is the main thing that will screw up sync.....
That being said, even with a buffer (assuming all the MDs use the same size buffer!) as long as LMCE used a UDP broadcast or multicast stream, this would significantly reduce the sync issue, as it is perfectly clear that in LMCE's case, the most significant issue for sync is the xine devices starting playback based on the last timestamp that media plugin received, which even if xine started playing back the stream instantly, could still be out by as much as 1 second!!!
