[linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]

[Dave Robillard]

On Sat, 2006-07-22 at 10:40 -0700, lazzaro wrote:
> > Dave Robillard <drobilla at connect.carleton.ca> wrote:
> >
> > OSC can go over TCP to avoid the packet loss issue (and messed up
> > ordering which can be extremely annoying as well).  liblo's TCP  
> > support
> > needs some work though.
> 
> 
> This comment illustrates an advantage for using RTP MIDI
> to send MIDI over lossy networks.  The recovery journal in
> RTP MIDI supports graceful recovery from the loss of an arbitrary
> number of packets upon the receipt of the first packet after the
> loss (also works for reordering).  Journalling is a feed-forward  
> process,
> no retransmission is used -- thus, no head-of-line-blocking latency
> issues as one has when running media over TCP.

Sure, for MIDI.  MIDI has a lot of built-in semantics you can use to
accomplish things like this, but OSC doesn't.  As Loki pointed out, MIDI
is no OSC (eg it sucks) :)

You could do it on a per-app basis (since you actually know something
about the information being transmitted), but a parallel to RTP MIDI
can't really be done for OSC (TCP isn't the only solution though, it
just happens to be what's around and obvious to use.  You can wrap OSC
in pretty much anything (and still be totally conformant))

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.

I need to do a bit of work on liblo to get TCP working better, but I'm
just going to use UDP for the former (realtime) and TCP for the latter
(reliable).

(On the local machine there's more fun possibilities like a POSIX
message queue backend for liblo or similar, but that's an aside I'm just
curious about at the moment)

-DR-