Subject: [linux-audio-dev] FWD: MWPP status report for IETF53
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Wed Mar 06 2002 - 01:11:39 EET
[LAD folks -- here's the status report for MWPP I just posted to the
IETF AVT group, complete with a URL for the new MWPP document. --jl]
---Hi everyone,
The latest revision of MWPP is out:
> Title : The MIDI Wire Protocol Packetization (MWPP) > Author(s) : J. Lazzaro, J. Wawrzynek > Filename : draft-ietf-avt-mwpp-midi-rtp-02.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-02.txt
New items include resiliency support for all MIDI Control Change controllers (including RPN and NRPN), reset semantics for the recovery journal system, and clarified delta-time semantics for pseudo-wire emulation.
Unfortunately, I'm not going to be making the trip to Minneapolis, below is the status report I would have presented ... comments welcome.
---
In Salt Lake, audience concerns were summed up as two questions:
Q1: What is normative and what is not? Q2: What is MPEG-specific and what is not?
The versions of draft-ietf-avt-mwpp-midi-rtp released since Salt Lake provide these answers:
Q1: What is normative and what is not?
A1: The format of the bits on wire, and the optional adherence to a sending policy that guarantees "graceful recovery" from packet loss, are the essential normative parts of MWPP -- these elements remain from the document presented at Salt Lake.
The rest of the Salt Lake document -- most notably, the detailed sending and receiving algorithms -- do not need to be normative. These were stripped out of the draft-ietf-avt-mwpp-midi-rtp series.
Q2: What is MPEG-specific and what is not?
A2: MPEG's requirement for mpeg4-generic support is the only MPEG-specific text left in draft-ietf-avt-mwpp-midi-rtp. The MPEG 4 Structured Audio document is no longer a normative reference.
After releasing the first post-Salt-Lake document, developers from several applications areas contacted me, who thought an IETF-approved MIDI protocol would be potentially interesting for:
* MIDI pseudo-wire emulation, to augment MIDI cables with Cat 5 on stage or in a studio.
* Resiliently streaming standard MIDI files, rather than the current practice of downloading the whole performance first.
But MWPP was only a starting point, and needed additional functionality to work in these contexts. Some of these features were added into draft-ietf-avt-mwpp-midi-rtp versions, including:
* A payload format that can carry many commands per packet, with a delta time system suitable for use in both pseudo-wire emulation and streaming MIDI file application domains.
* A payload section that can (non-resiliently) code the entire MIDI wire protocol, including support for embedded System Realtime commands, arbitrarily-large System Exclusive commands, and System Exclusive commands that code information in the relative timing of internal data octets.
* Resiliency support for all 128 MIDI Control Change numbers, including the MIDI RPN and NRPN systems, and semantics for the entire resiliency system in the case of MIDI reset events.
The main focus going forward is to complete the list of additions MWPP needs to be a general MIDI transport. Work items include:
* Resiliency support for all MIDI System commands (including MIDI System Exclusive commands) where it makes sense to do so -- i.e. commands sufficiently short and real-time oriented that the recovery journal mechanism makes sense.
* For bulk-data MIDI Systems commands, where the recovery journal mechanisms are not appropriate, define an alternative mechanism (as simple as "protect messages X Y and Z by other means", or perhaps something more detailed).
------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Wed Mar 06 2002 - 01:00:30 EET