23 Jul
2006
23 Jul
'06
9:27 p.m.
On Jul 23, 2006, at 2:06 PM, Dave Robillard
<drobilla(a)connect.carleton.ca> 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
---
23 Jul
23 Jul
9:41 p.m.
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,
what sort of latency is this? ~10 ms? couldnt adjusting the MTU or something else
alleviate it without having to invent "UDP + Parity Checking" ?
24 Jul
24 Jul
5:27 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Sun, 2006-07-23 at 16:27 -0700, lazzaro wrote:
On Jul 23, 2006, at 2:06 PM, Dave Robillard
<drobilla(a)connect.carleton.ca> wrote:
Yeah, the latest value being lost is the problem, if you wanted to
really solve this problem you need to make sure that value actually gets
there (which you could probably do in a similar/identical way that RTP
MIDI does)
You're missing the big overriding point here though: RTP Midi solves
this transmission problem, yes - but it solves it for _MIDI_. Using
incredibly disgusting SYSEX concoctions is simply not an acceptable
substitute for what many people (in this myself and Loki) use OSC for.
Noone who's already gone OSC would ever actually switch back to MIDI
(especially custom sysex evil that throws interoperability completely
out the window). Human readability and interoperability IS often
important (eg using supercollider or pd or whatever to control things).
It's like pitching a modem solution to a web server problem - I'm sure
its a very nice solution for modems, but noone's making a web service
that speaks the Hayes command set any time soon are they? ;) Anyway, as
soon as you go sysex you lose the semantics and you have the same
problem anyway - retransmission is the only possible solution if you
know nothing about the data (it becomes application specific). RTP MIDI
may be fantastic for what it does, but it's definitely no solution for
OSC things like this - there's a reason you don't see things like
Supercollider, Om/Ingen, etc using MIDI for client/server comms.
Anyway, this problem could easily be solved in the app if the values are
echoed back (as mine are) by just resending the latest value if it
didn't make it. In practise - like most people - I don't actually
control realtime audio stuff over lossy networks in situations where
latency matters anyway, so I havn't bothered. It would be trivial to do
though.
-DR-
(P.S. the latency incurred by using TCP on an even remotely decent
network isn't nearly as bad as people tend to assume when this comes up)
^M
^M
ATH0
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.
6771
days inactive
6772
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
carmen -
Dave Robillard -
lazzaro