[LAU] MIDI over wifi on Linux, revisited

Jonathan E. Brickman jeb at ponderworthy.com
Mon Jan 4 18:55:52 UTC 2016

> 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.
Agreed.  A panic button, for me (a multidevice keyboardist), is about as 
useful as a power button.  If my architecture needs a panic button, my 
architecture isn't good enough for me.
> 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.
Of all the current code bases in this thread, which are all the ones I 
have heard of thus far, indeed, rtpmidi with journaling does sound the 
best to me.  Anyone have, or know of a source of, the old midistream 
source .deb for Ubuntu?  It is reported as "no longer available", I 
wonder if there was a patent / copyright issue or something.

But in truth, I don't want any risk of out-of-order, or missed, commands 
in the stream.  Delay is fine, only as a great indicator that I have to 
abandon wireless and use my backup wired approach. If I'm spraying notes 
around as fast as my fingers will go on my 88's for consecutive minutes, 
nothing shall be out of order, or something has to get switched out.

Which, strangely enough, brings me right back to primordial methods.  
After all, even audio and video streaming over a gigabit wired LAN 
depends on caching if it's going to be hifi and truly flawless, TCP/UDP 
was never designed to keep packets in original order.

I really do wonder.  What about this for Linux-to-Linux MIDI:

- Processes on each end of the link connect to their respective MIDI 
port devices via simple binary opens
- The processes set up two TCP connections over the LAN, two separate 
TCP ports, one for each direction of data flow
- The processes set up two Zmodem connections, small block sizes, one 
connection each direction, one per TCP port

Anyone know why this should not be maximally reliable and low-latency 
too?  We don't have to worry about any of the details of the data being 
transmitted; Zmodem handles what history needs there are; either the 
wifi rig is good enough or not.

Jonathan E. Brickman   jeb at ponderworthy.com   (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available! 
Music of compassion; fire, and life!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160104/3ce1887f/attachment.html>

More information about the Linux-audio-user mailing list