Multimedia Networks Group
Networking Research at the University of Virginia
University of Virginia>Computer Science Dept.> Multimedia Networks Group> projects>mmidi 

      Introduction, Research Statement...

      Faculty, Postdocs, Students, Alumni...

      INDRA, QoSbox, HyperCast, RouteConfig, VintLab, Traffic Engineering...

      QoS Networks, Super-Scalable Multicasting, Hybrid Fiber Coax Networks...


 Private Links 
      For group members only.


MMidi: The MBONE Midi Tool

Synchronizing Digital Music in a Multicast Network

In the realm of networked multimedia there currently exist applications with which people can share audio, video, drawings, and collaboratively browse the web. Musicians, however, currently have no method of networked collaboration. Digital music requires tight synchronization of a different sort than is used in audio and video.

Digital music sends very small packets of performance-critical data. Errors in timing and synchronization are much more obvious to the listener than are errors in digital audio playback. Buffering and excessive delay are unacceptable methods of compensating for network irregularities because of the timing constraints imposed by correct playback criteria. Musicians need reasonable delays between actuation (the pressing of a key) and instrumentation (the audible expression of a note). The delay between actuation and instrumentation needs to remain constant in order for a musician to correctly play. Variable delays introduced by buffering or network jitter are unacceptable.

Other techniques used for synchronizing multimedia streams, such as resynchronizing between 'talk spurts' are inappropriate because digital music lacks clearly definable bursts. In a musical performance, notes tend to play at a constant rate, and silent periods are not long enough to use for synchronization. Additionally, such resynchronizations typically involve compressing or extending the silent space between talk spurts, and such alterations in silent pauses are unacceptable in a musical performance. Digital music offers synchronization challenges similar to those overcome by other MBONE software, however typical synchronization techniques fail to provide adequate support for this media.

The MMidi protocol and the applications that use it will help musicians on the internet collaborate and interact musically. It supplements the MIDI data format to compensate for unreliable or unpredictable network service. The protocol uses a target playout horizon that is sender-based, but negotiated in the network. Once set, the horizon is not moved during a performance. Likewise, all delays and buffering are adjusted with respect to this event horizon. The MMidi protocol improves on previous research in this field by offering an adaptive, scalable, standards-compliant, application which runs on a wide variety of system configurations. The MMidi applications are also well suited to be integrated into multimedia suites or larger applications.

The MMidi Protocol

MMIDI is the protocol I am developing to handle the various needs introduced by the unreliable internet.

The idea is that there is not enough information available in standard MIDI because it assumes a completely reliable transmission medium. Since the internet is not such a medium, more information must be added to the MIDI protocol to make it robust to the problems of the internet.

MMidi adds continuation messages to standard MIDI. For example, standard MIDI sends only note on to indicate that a note has been turned on. It later sends note off to indicate that the note was turned off. MMidi will send note on at first, but it will continue to send note still on messages to assure the recipients that the notes are still on. Recipients, likewise, automatically shut off a ringing note if they do not receive note continuation messages.

MMidi is a payload type of RTP . It uses RTP and RTCP as the transport protocol. It conforms to most of the RFC's guidelines now, and will conform to all of them as soon as I can manage it.

The MMidi Packet Format

This is subject to change, as the program evolves. Once I release the code and/or binaries, I'll fix the packet format. The MMidi part of a typical RTP data packet looks like the following:

0   ..   7 8   ..   15 16   ..   23 24   ..   31
MIDI event MIDI param 1 MIDI param 2 [D] [Extension]

Explaining the packet format

MIDI Event [8 bits]
This is the first octet of a MIDI event, as delivered by the MIDI hardware (or simulated compatible with standard MIDI).

MIDI param 1 [8 bits]
First parameter octet

MIDI param 2 [8 bits]
Second parameter octet

D [1 bit]
Duplicate bit. When set, it means that this is a duplicate of a message that has already been sent. Primarily used for note on or note off messages to ensure that they are processed correctly.

Extension [7 bits]
For MIDI messages (such as SysEx) that send variable amounts of data, this indicates how many 32-bit words follow.

The Applications

The MMidi System is composed of 2 applications and a utility that helps test the system.


MMidi is the user interface which enables the user to play notes. It uses the MMidi protocol to synchronize playback with other senders in the performance. It also has some limited sound capabilities which enable it to play notes on a sound card.


MNFP is the Midi Network File Player. It reads a MIDI file, and plays the notes into the network, using the MMidi protocol. It has a very simple interface.


MRepD is an MBone Repeater/Delayer. It listens on one multicast address, delays the packets that it hears for a specified amount of time, and then repeats the packets to another multicast address. Several parameters can be configured, such as the amount of delay, the percentage of packets dropped, and the variance on the delay.

For more information on this project, mail


© 1996-2003 Multimedia Networks Group. Please send feedback to Jörg Liebeherr.