Re: Lost Midi Packets over Wifi Network
Re: Lost Midi Packets over Wifi Network
- Subject: Re: Lost Midi Packets over Wifi Network
- From: John Lazzaro <email@hidden>
- Date: Sat, 25 Feb 2012 10:27:43 -0800
Hi everyone,
I was the editor for RFC 6295/4295/4296,
the RTP MIDI RFCs ... I'm posting to
clear up some issues brought up earlier
on the thread. I'm not speaking for the
IETF, the MMA, or Apple here -- just me.
A well-behaving Wi-Fi network will drop
about 1% of IP packets. If you sent
MIDI channel commands over UDP on
a network like this without using the
recovery journal for the MIDI channel
commands, within a few minutes you'd
have stuck notes, and sliders and buttons
that are permanently out of sync on the
sender and receiver ends. We don't see
this behavior in Apple's implementation,
and so the recovery journal must be in use.
Now, what happens when you have an
extended network drop-out, say 1 or 2
seconds? Well, let's imagine you are
streaming audio over this network,
in a pro-audio usage scenario (i.e. the
usage scenario wireless mic systems
are built for). What behavior do you want
out of the system after the drop-out is over?
The only sensible behavior is
to discard the audio that would have
played during the gap. RTP MIDI is
designed in the same way -- once a
drop-out exceeds a "reasonable" time,
NoteOn's played during the drop-out
will get discarded. What RTP MIDI
does do, however, is guarantee that
the "state" of the receiver is unaffected
by the gap -- so, if a NoteOff was in
the gap, that NoteOff is still seen
by the receiver, and so stuck notes
never happen, for example.
Fundamentally, if you're in a situation
where this behavior is unacceptable
(and yes, a network on a touring
show may qualify as such), the
best solution is to install industrial
strength Wi-Fi in your stage rig --
like the Cisco access point with
six external diversity antennas that
is hanging on the ceiling outside
my office door. Strategically place
several of those on your stage rig, and
the drop-outs should become a "once
per tour" sort of event instead of a
"several times per show" event.
Finally, with respect to SysEx ...
RTP MIDI offers recovery journal
tools for all of the System Commands,
including SysEx. The SysEx protection
is practical for sparse streams of short
SysEx commands, and becomes less
practical for denser SysEx streams or
longer SysEx commands. The limitation
stems from the assumption that the
sender and receiver is not going to
have a database of the SysEx commands
for all of popular MIDI devices in history
at its disposal, and so the semantics of
the commands will be opaque. If support
for SysEx commands of arbitrary length
and density is essential, RTP MIDI suggests
bonding a TCP and a UDP channel to
send a single MIDI cable is supported
by RTP MIDI, and offers tools for this option.
More generally, for SysEx and all other commands,
it's up to the implementor to decide what
to protect and what to leave unprotected.
We did the best we could when designing
RTP MIDI to offer practical tools for each
of the command types, given the limitation
of being compatible with 30 years of MIDI.
Ultimately vendors are responsible for deciding
which tools ro implement for their user base.
--
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden