23 Jul
2006
23 Jul
'06
1:15 a.m.
On Sat, 2006-07-22 at 10:40 -0700, lazzaro wrote:
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-
Dave Robillard
<drobilla(a)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.