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.