[AVT] summary for draft-lazzaro-avt-mwpp-midi-nmp-00.txt

Hi everyone,

Sorry for the delay, this is the summary for
draft-lazzaro-avt-mwpp-midi-nmp-00.txt, I'll be presenting in the
Monday PM session.

                    --- summary begins here ---

MWPP (the MIDI Wire Packetization Protocol,
draft-lazzaro-avt-mwpp-midi-nmp-00.txt) is an RTP packetization to
support "band practice over the Internet" applications, where
musicians located in different locations perform together as if they
were in the same room. The "M" in MWPP is MIDI, a control stream that
electronic musical instruments generate to describe physical gestures
musicians make (press down piano keys, release them, etc). We've
prototyped MWPP in sfront, our freely-redistributable softsynth:

http://www.cs.berkeley.edu/~lazzaro/sa/
http://www.cs.berkeley.edu/~lazzaro/nmp/

so Linux users can download sfront and play around with demos based on
MWPP.  We also presented a "case for NMP" paper at NOSSDAV this
summer, that describes how MWPP works in practice:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf

The presentation in SLC will hit the following points:

  o  A few slides introducing the application.

  o  MWPP controversies surrounding time: unlike most audio packetizations,
     playout buffering for jitter removal is infeasible for MWPP,
     because end-to-end latency needs to be quite low for musical
     performance to work. MWPP is designed for MIDI commands to be
     executable on receipt by the receiver -- the receiver models the
     nominal latency of the link, and uses its knowledge of the semantics
     of each type of MIDI command to "do the right thing" if a packet is
     "late."

  o  MWPP controversies surrounding resiliency: MIDI is a very fragile
     command language -- a single lost command is indefinitely catastrophic
     (think of what happens if the "turn this note off" command is lost --
     the note "hangs" and plays forever!). MWPP has a FEC-like reliability
     system built into the protocol to address this issue, which is 
     multicast compatible, and only uses the standard RTCP SR/RR reports.

  o  MWPP controversies surrounding MPEG: MWPP was designed for use with
     MPEG 4 Structured Audio (a normative softsynth that is part of MPEG 4
     Audio, which our sfront prototype uses). However, we envision most
     users of MWPP to be non-MPEG-4 softsynth users, since in practice
     Structured Audio has not taken off in the softsynth marketplace yet.
     So, MWPP supports two types of underlying transport: "RFC-generic"
     for MPEG 4 Structured Audio folks, and raw RTP for non-MPEG folks.

Finally, the presentation doesn't exist yet -- I'm starting it as soon
as I send this summary off to the list :-). So, if you have requests
for topics to cover, or if you think these topics above are not
appropriate, send me email and I'll adapt the talk to suit the needs
of the WG. Thanks!

						--john lazzaro
						  lazzaro@cs.berkeley.edu

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www1.ietf.org/mailman/listinfo/avt