RTP-MIDI
It is completely open and free (no license is needed), and is compatible both with LAN and WAN application fields.
[2] In parallel, another document was released by Lazzaro and Wawrzynek to give details about practical implementation of the RTP-MIDI protocol, especially the journaling mechanism.
In 2006, the Dutch company Kiss-Box presented a first embedded implementation of RTP-MIDI, in different products like MIDI or LTC interfaces.
Kiss-Box announced released in 2012 a new generation of CPU boards, named "V3", which support the session initiator functionalities.
Availability of drivers have been announced on some forums, based on the original work of Nicolas Falquet and Dominique Fober.
A full implementation of RTP-MIDI (including the journalling system) is available within the Ubuntu distribution, in the Scenic software package.
[12] There is a new implementation, rtpmidid,[13] that integrates seamlessly with the ALSA sequencer, allowing use of tools like QjackCtl to control the connections.
Apple added full CoreMIDI support in their iOS devices in 2010, allowing the development of MIDI applications for iPhone, iPad and iPods.
KissBox produces an RTP-MIDI OEM module, an external communication processor board, which connects over an SPI bus link.
In order to simplify integration, it was decided to use an external network processor board handling the whole protocol stack.
This synthesizer is fully programmable using a virtual patch concept, similar to Max/MSP, and includes a full MIDI support.
AVB is a set of technical standards which define specifications for extremely low latency streaming services over Ethernet networks.
RTP-MIDI protocol can also use the real-time capabilities of AVB if the device implements the RTCP payload described in IEEE-1733 document.
RTP-MIDI sessions are also able to provide a "patchbay" feature, which required a separate hardware device with MIDI 1.0 connections.
These two protocols are however quite heavy to implement especially on small systems, especially since they do not constrain any of the parameters enumerated in the session descriptor, like sampling frequency, which defines in turn all fields related to timing data both in RTP headers and RTP-MIDI payload.
Both partners then know the difference between their respective clocks and can determine the offset to apply to Timestamp and Deltatime fields in the RTP-MIDI protocol.
This technique makes it possible to compute the average latency of the network, and also to compensate for a potential delay introduced by a slow starting thread, which can occur with non-realtime operating systems like Linux, Windows or OS X. Apple recommends repeating this sequence a few times just after opening the session, in order to get better synchronization accuracy, in case one of them has been delayed accidentally because of a temporary network overload or a latency peak in a thread activation.
This sequence must repeat cyclically, between 2 and 6 times per minute typically, and always by the session initiator, in order to maintain long term synchronization accuracy by compensation of local clock drift, and also to detect a loss of communication partner.
Some implementations, especially on personal computers, also display an alert message and offer to the user a choice between a new connection attempt or closing the session.
The journalling mechanism permits to detect MIDI messages loss and allows the receiver to generate missing data without needing any retransmission.
It can however easily be shown that a correctly programmed RTP-MIDI application or driver does not exhibit more latency than other communication methods.
This applies to any communication protocol, IP related or not, since most operating systems, including Windows, Mac OS or Linux, do not allow direct access to the Ethernet adapter.
When a RTP-MIDI application wants to send a packet to a remote device, it must locate it first on the network, since Ethernet does not understand IP-related concepts, in order to create the transmission path between the routers/switches.
With modern processors, this preparation is extremely fast and takes only a few microseconds, which is negligible compared to the application latency itself.
However, the latency introduced at this level is generally extremely low since the driver threads in charge of the network adapters have very high priority.
The AES started a working group named SC-02-12H[27] in 2010 in order to demonstrate the capability of using RTP payloads in IP networks for very low latency applications.
The draft proposal issued by the group in May 2013 demonstrates that it is possible to achieve RTP streaming for live applications, with a latency value as low as 125 microseconds.
RFC 3927 [28] describes a common method to automatically assign IP addresses, which is used by most RTP-MIDI compatible products.
A minimum configuration would be then to assign a name to the device before connecting it to the network, which voids the "true Plug&Play" concept in that case.
It is technically impossible to perform the complete installation of any networked device (related to MIDI or not) just by abstracting the addressing layer.
