On Jul 23, 2006, at 2:06 PM, Dave Robillard <[EMAIL PROTECTED]> wrote:
I don't see it as much of a problem anyway. At least in all my use cases, there's realtime crucial data (eg what MIDI tends to do, controllers, notes, etc) and there's data that just needs to get there sanely. The nice thing about the realtime stuff is that lost messages don't really matter, all you care about is the most recent one anyway.
Well, consider a volume slider on a mixing console. One way to send its state is to sample its value and send a packet every millisecond. In this case, your "nice thing" is true -- the occasional burst of lost or reordered packets will only cause brief "transient" artifacts. The price paid for this "nice thing" is sending 1000 packets per second, every second of the performance. The more efficient way to send the slide state is to only send packets when a human finger moves the slider. In this case, your "nice thing" is not true -- the slider might be moved by the human once per minute, and if the packet coding that move is lost, that lost packet matters for the entire minute. RTP MIDI's recovery journal lets you safely use this incremental update approach over a lossy packet stream in an efficient way ... if you need to send data over lossy networks and that fits MIDI's semantics, and TCP's head-of-line blocking latency is not acceptable, I think RTP MIDI is the right protocol to use. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---
