[e2e] Protocols for tightly synchronised multicast?

[David P. Reed]

Buffering is so cheap, why try to avoid it?  Just synchronize clocks at all 
the receivers and transmit.

Use Tornado coding on multiple levels of quality, and you can even handle 
receivers that have different effective bandwidths from the source fountain.

Of course the problem is already highly redundant - if each transducer can 
hear the others, then there is much less need for identical information to all.

- David

At 05:49 PM 8/14/2001 -0400, Simon Spero wrote:
>Does anyone have any suggestions for a multicast transport capable of
>delivering packets to applications on multiple clients synchronised to
>within a few milliseconds?
>
>The idea is to try and build a distributed virtual sound-system; a single
>source would send a single stream of audio data; this data would be
>recieved by multiple clients, with the data sent to each clients speakers
>with a fixed delay relative to some global clock (the delay would be based
>on the client's physical distance from the center of the virtual system,
>
>I can see how one could roll ones own using timestamps and NTP, but it'd
>be nice if I could use an existing transport
>
>Thanks for any suggestions
>
>Simon