On Mon, 4 Jan 2016, Jonathan E. Brickman wrote:
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.
midistreamer seems to have been a part of scenic that was pulled into a
separate package in debian. midistream is still a part of scenic and will
be built as part of that. That is building scenic will build midistream as
a separate file still. scenic seems to be the GUI that controls this. The
README does not indicate if it is possible to just build midistream on
it's own... (which you may have to do as gtk has moved on since the last
updates)
So I would try a git clone
https://code.sat.qc.ca/redmine/unsupported/scenic.git
./configure
make midistream
and see if it gets you there.
- 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
If you use TCP it will give you right ordered no missing parts streaming,
no need for z/xmodem to do that. I would add a bit of code to make sure to
only use full events in any packet. Making it a jack client would do that
by default. (Even for sysex... it just won't handle very big sysex events
:)
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.
The lowlatency part is based on collisions, something most of us have
forgotten (younger ones may have never had any) in this age of switches.
Ethernet deals with collisions by both sending systems waiting a random
amount of time and trying again. WIFI does the same, but in crowded
airspace you have not only collisions between you and your AP (which you
can control) but also between you and (as mentioned) everyone else's AP
and cell phone and... whatever. That retry can end up being in seconds...
which is ok for streaming video with a big buffer and error correction
stuff that fakes it when things are missing. Not for stage.
WIFI does use some methods of dealing with more than one signal at a time
(frequency hopping etc.), but it is not really a low latency thing. But
you might get lucky sometimes in some venues.
Anyway, it sounds like a fun project. If my laptop was working right I
would play with it.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
