4 Jan
2016
4 Jan
'16
9:19 p.m.
Jonathan Brickman:
...
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.
UDP is what you are talking about.
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
TCP provides reliable, ordered, and error-checked delivery
of a stream of octets between applications running on hosts
communicating over an IP network.
so TCP solves the in order reliable thing, but might give you jitter
and latency.
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.
Two processes, one at each end, just pushing a midi byte stream over a
TCP connection (socketpair) "should work", but you might need some kind
of session control. Everything you put in on one should get out on the
other side, barring something that makes the socketpair to go down.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57