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).
Why, exactly, is existing MIDI/OSC-over-TCP due to retransmissions?
We're talking about a 31.5 kHz real data stream, why is that
necessarily slow in response when encapsulated in a wireless
connection whose speeds start in the megabit range? Is timeout
detection really that long? It is sounding like we need a much
shorter timeout for this, something a lot more like DNS-over-TCP?
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...
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Will be studying, thanks!