[LAU] MIDI over wifi on Linux, revisited
len at ovenwerks.net
Mon Jan 4 17:07:17 UTC 2016
On Mon, 4 Jan 2016, Christopher Arndt wrote:
> Am 04.01.2016 um 00:30 schrieb Len Ovens:
>> MIDI, unlike audio, must have 100% reliablility to be useful.
> Despite all the theorizing about which network protocol works best for
> MIDI, the TouchOSC appp for iOS/Android just sends MIDI messages as OSC
> via UDP  and in practice, this works very well and reliable in my
> home wifi network, even with encryption.
> I use this without problems to control soft synths loaded into Carla via
> my iPad using the the software touchosc2midi . Works very well for
> parameter control via control change messages, but the latency is even
> low enough to be able to play notes on the tablet, if the timing doesn't
> need to be too accurate. I haven't had any dropped messages yet.
I think (from what I have read of the OP setup) that this case has two
things that call for reliablility.
1) The MIDI stream is heavy. It includes the whole backing orchestration.
The use of a panic button would be very noticable. (maybe more so than the
hung note it was correcting)
2) The person controlling the playback is playing a sax over top of it and
therefore needs his hands to play that. That is he has no way of
monitoring and manually correcting things.
I can not see how adding OSC as yet another layer with no error checking
or correction could be any better than ipmidi.
rtpmidi with journaling looks to be the best bet on this because there is
no resend needed. The journaling info is sent if needed or not so there is
much less latency required for error correction. Journaling does not cover
all possibilities BTW, but it is very picky about note off events. In the
case of controllers the last value is journaled rather than the whole
string of values.
I think any of these protocols are event based so that
the likelyhood of partial events showing up is minimized. I am not sure
how sysex events longer than packet size are handled, but it would be
simple enough to add sequence numbering and not start forwarding a sysex
till the whole thing reaches the receiving end. So really it is only
performance data where one event completes another that is at issue.
More information about the Linux-audio-user