[LAU] MIDI over wifi on Linux, revisited

Hanspeter Portner dev at open-music-kontrollers.ch
Sun Jan 3 08:28:39 UTC 2016

On 03.01.2016 03:24, Jonathan Brickman wrote:
> Some may remember, I tried a full-court press on MIDI over wifi about
> eighteen months ago, using a couple of different methods; there were
> occasional losses in realtime play, enough key-up commands lost that it
> could not be used.  So I gave it up for then and eventually found a
> different use for my Rpi2.
> But the prevalence of tablets as OSC+MIDI controllers, over wifi, has
> not ceased to nag at me.  I'm not interested in having a tablet -- my
> keyboard is all I need -- but I am very interested in configuring an
> RPI2 or equivalent in place of that tablet, so that I can wire keyboard
> to RPI2 and then go wireless to the synth. 
> Now if I understand this Wikipedia article
> <https://en.wikipedia.org/wiki/Open_Sound_Control> correctly, SLIP is
> commonly used to encapsulate OSC signals.  This could be a great clue,
> because SLIP is very definitely a protocol which can give us
> verification and recovery of lost signals, i.e., signals lost in the
> normal wifi situation.  And I have seen the Pure Data method of
> converting OSC to MIDI and back, so that is not too much of a problem. 
> The question I have is, what would be the best method of verifying,
> configuring, and debugging SLIP encapsulation?  To do this well, for
> production on stage, I have not not only be able to checkbox on for
> SLIP, but trigger warnings if it detects a certain degree of errors.
> Thoughts, anyone?

As others have pointed out already, SLIP is merely used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).

First decision you have to take is if you want to go UDP or TCP. As you
want to do live input, TCP may be too slow on wireless because of
frequent retransmissions.

Depending on what you want to do, TCP may just be good enough. Thus
simply use any of the available OSC and network MIDI libraries
(RTP-MIDI, ipMIDI, ...) in TCP mode (if the library should support it).

If you need it to be more responsive, you want to use UDP. As you have
seen, UDP packets tend to get lost on wireless. The solution is to use a
means of transport insusceptible to lost packets.

For OSC, you can use TUIO1 [1] or TUIO2 [2]. They quite elegantly
circumvent the problem of lost packets by transmitting (almost) full
state information. There are numerous implementations out there [3].

[1] http://www.tuio.org/?specification
[2] http://www.tuio.org/?tuio20
[3] http://www.tuio.org/?software

For MIDI, use RTP-MIDI [4] with enabled journaling. The RTP-MIDI journal
enables clients to recover from lost packets (the journal contains
critical state information). I am not sure whether there is a readily
available implementation of RTP-MIDI journaling for GNU/Linux, though.

[4] https://tools.ietf.org/html/rfc4695

As a workaround, it may be fun to encode MIDI to TUIO at the sender and
decode it back at the receiver...

More information about the Linux-audio-user mailing list