|
Home
Introduction, Research Statement...
People
Faculty, Postdocs, Students, Alumni...
Projects
INDRA, QoSbox, HyperCast, RouteConfig, VintLab, Traffic Engineering...
Papers
QoS Networks, Super-Scalable Multicasting, Hybrid Fiber Coax Networks...
Sponsors
Private Links
For group members only.
Site-Index
|
|
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
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
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
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 paco@cs.virginia.edu.
|