<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote cite="mid:5688DBB7.4030901@open-music-kontrollers.ch"
type="cite">
<pre wrap="">
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).</pre>
</blockquote>
Got it. SLIP frames the data, but does not do retransmission.<br>
<blockquote cite="mid:5688DBB7.4030901@open-music-kontrollers.ch"
type="cite">
<pre wrap="">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).</pre>
</blockquote>
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?<br>
<blockquote cite="mid:5688DBB7.4030901@open-music-kontrollers.ch"
type="cite">
<pre wrap="">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] <a class="moz-txt-link-freetext" href="http://www.tuio.org/?specification">http://www.tuio.org/?specification</a>
[2] <a class="moz-txt-link-freetext" href="http://www.tuio.org/?tuio20">http://www.tuio.org/?tuio20</a>
[3] <a class="moz-txt-link-freetext" href="http://www.tuio.org/?software">http://www.tuio.org/?software</a>
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] <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc4695">https://tools.ietf.org/html/rfc4695</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:Linux-audio-user@lists.linuxaudio.org">Linux-audio-user@lists.linuxaudio.org</a>
<a class="moz-txt-link-freetext" href="http://lists.linuxaudio.org/listinfo/linux-audio-user">http://lists.linuxaudio.org/listinfo/linux-audio-user</a>
</pre>
</blockquote>
Will be studying, thanks!<br>
<br>
<div class="moz-signature">-- <br>
<div style="color: #993300; font-size: 0.8em; font-style: italic;">
Jonathan E. Brickman <a class="moz-txt-link-abbreviated" href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977<br>
Hear us at <a href="http://ponderworthy.com">http://ponderworthy.com</a>
-- CDs and MP3 <a
href="http://ponderworthy.com/ad-astra/ad-astra.html">now
available!</a><br>
Music of compassion; fire, and life!!!
</div>
</div>
</body>
</html>