Re: Lost Midi Packets over Wifi Network
Re: Lost Midi Packets over Wifi Network
- Subject: Re: Lost Midi Packets over Wifi Network
- From: Michael Tyson <email@hidden>
- Date: Sat, 25 Feb 2012 20:07:53 +0100
Thanks for chiming in, John! This is very interesting.
On 25 Feb 2012, at 19:27, John Lazzaro wrote:
> 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
_______________________________________________
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