Comparison of MIDI-Over-IP Protocols
Protocols for MIDI-over-IP can be classified along several dimensions:
- Type and scope of the underlying network (e.g. private LAN, public LAN
or Internet (WAN).
- Intended use: e.g. Streaming MIDI (non-interactive music playback), Show
Control,
Interactive Performance
- Acceptable performance levels (latency, jitter, capacity, error rates
and recovery).
Intended Use |
MWPP
|
DMIDI
|
NetMIDI
|
MIDIOverLAN+
|
iMIDI
|
Streaming MIDI |
Y
|
-
|
-
|
-
|
-
|
Show Control |
-
|
-
|
Y
|
-
|
-
|
Interactive Performance |
Y
|
Y
|
?
|
Y
|
Y
|
Network Aspects |
MWPP
|
DMIDI
|
NetMIDI
|
MIDIOverLAN+
|
iMIDI
|
UDP/TCP |
Both
|
U
|
U
|
U
|
T (?)
|
Private LAN |
N
|
Y
|
(?)
|
Y
|
N (?)
|
WAN |
Y
|
N
|
N
|
N
|
N (?)
|
MIDI Streams |
1-N
|
N
|
32*N
|
16
|
1 (?)
|
Timestamps |
Y
|
N
|
N
|
Y
|
N (?)
|
Error Handling |
Y
|
N
|
N
|
N
|
Y (?)
|
Overhead |
M-H
|
L
|
L
|
L
|
H
|
Latency |
M-H(?)
|
L
|
L
|
L
|
H
|
Notes:
Please refer to the brief primer below (or additional references
at the end) if any terminology is unfamiliar.
UDP/TCP
|
Protocol uses UDP (fast, unreliable) or TCP (slow, reliable)
See discussion of UDP, TCP in "PRIMER" section. MWPP is specified
for UDP, but can use TCP.
|
Private LAN
|
A private LAN is used solely by MIDI-related traffic (no
file transfers, Internet access, print jobs, etc.).
Y: protocol authors recommend use of dedicated LAN
to avoid jitter and latency problems.
|
WAN
|
Y: protocol is designed for streaming MIDI over the public
Internet (WAN: Wide Area Network)
|
MIDI Streams
|
Number of distinct 16-channel MIDI streams supported to
a given IP network address (in either direction).
- NetMIDI uses 32 groups per "Show Namespace"
(2^32 namespaces)
- DMIDI specifies destination by 'Pseudo SysEx ID', and
has one stream per ID (but N IDs per IP address)
- MIDIOverLAN+ has 16 "LAN-Out" ports and 16
"LAN-In" Ports
|
Timestamps
|
Protocols without timestamps (DMIDI, NetMIDI, probably iMIDI)
cannot queue traffic ahead and __may__ have more jitter (especially on
non-private LAN)
|
Error Handling
|
UDP-based protocols have no error recovery, but can use
a Checksum (optional) to detect packet corruption.
Y: protocol has additional error detection and recovery,
or uses TCP (which provides both).
Note: DMIDI uses UDP Checksums. NetMIDI could use UDP Checksums
(but does not) NetMIDI also has message numbers that could be used to
detect dropped packets in a future version of NetMIDI
|
Overhead
|
Estimated processing overhead: Low, Medium or High MWPP
usage varies according to which error handling features are used.
|
Latency
|
Relative estimated latency: Low, Medium or High.
MWPP latency for WAN is High (obviously).
MWPP latency for LAN varies per overhead of enabled error
handling features.
|
Comments
The protocols surveyed fall into three basic groups:
- Simple UDP-on-LAN protocol: DMIDI, NetMIDI, MIDIOverLAN+
- Simple TCP-on-LAN protocol: iMIDI
- Multi-facted WAN-capable protocol: MWPP
DMIDI and NetMIDI are technically fairly similar, with clear differences
in MIDI destination addressing. (see subsection on Node Addressing and UDP Protocols,
below). Note that, since neither DMIDI nor NetMIDI use timestamps, all MIDI
events in the same packet must occur at the same time (immediately on receipt).
This produces a somewhat inefficient use of network bandwidth (many short packets),
which is negligible in most cases. The author of NetMIDI states that typical
transit times are < 150 microseconds, and that in most cases NetMIDI should
deliver more pleasing performance than "non-priority boosted legacy MIDI".
MIDIOverLAN++ is related to MIDI and NetMIDI, but uses timestamps
and adaptive algorithms with the intent of improving jitter performance.
iMIDI uses TCP, and should be considered a "toy" protocol
at present.
|