Subject: Re: [AVT] new MWPP I-D ...

From: John Lazzaro <[email-masked]>
Date: Mon, 23 Sep 2002 13:38:15 -0700

> Colin Perkins <[email-masked]> writes:
>
> Can you expand on the use for these untimed commands? What is the reason
> they can't be timestamped as they are generated? 

There are two separate issues here ...

[1] The actual "untimed command" scenario I was considering was a
"panic button" situation. Imagine a sender sending a high-latency MIDI
stream to a receiver, who is buffering 100ms of command time
locally. There are situations where a sender might want to
communicate:

  -- Discard the unexecuted MIDI commands in your local buffer, and
  -- Execute the provided list of MIDI command immediately
     (which would typically be commands that do "reset"
     functionality, like the "All Notes Off" commands).

This is inexpressible in a single MWPP stream, because you can't
"backdate" new commands -- all timestamps are monotonically
increasing. Neither could you really express it using two streams --
you can do the backdating, but you can't express the "flush the
buffer" concept.

I don't know if its really worth the effort to add this into MWPP,
though -- thus the appearance of the item in the "features to ponder"
list and not the "change log for -05.txt" list.

[2] Martijn's actual situation, which relates to MIDI sequencers that
combine low-latency live data with canned MIDI tracks. From his AVT
posting earlier today, it appears we're both in agreement now that
using multiple streams (a high-latency and a low-latency stream) that
both target the same MIDI name space is the best way to implement the
application, rather than add "dual-latency" features to the MWPP spec.

The remaining issues revolve around the text in Appendix C.4 that
mandates sender and receiver requirements to ensure the integrity of
splitting and merging a 16-voice + system MIDI name space into
multiple MWPP streams ... to quote his posting:

> There is, as far as I can see, only one problem with this
> approach. The sender cannot know exactly how both streams are going to
> be merged. The meaning of (N)RPN messages (and perhaps others?) may
> change when interleaved.

Basically, C.4.1 mandates that senders are not allowed to send streams
that have ambiguous merging semantics -- so, in the case of (N)RPNs,
if senders segregate all traffic for a particular MIDI voice channel
to one MWPP stream, all will be well. If this approach is too
restrictive for an application, then senders need to manage the two
streams in a finer-grained way, to ensure unambiguous semantics.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Martijn Sipkema" <[email-masked]>
Date: Tue, 24 Sep 2002 00:03:11 +0100

[...]
> you can do the backdating, but you can't express the "flush the

Also apart from flushing (discarding) the buffer, draining it immediately
might somtimes be usefull.

[...]
> streams in a finer-grained way, to ensure unambiguous semantics.

This approach is not unacceptable, but I really hope a better way of
handling
(N)RPNs (and possibly other non-atomic messages) is be possible. I'm not
sure
how they are best handled.
If only for (N)RPNs, the receiver could be mandated to keep state
(current parameter) for a 'midiport' and handle (N)RPNs that way I
suppose...

--martijn

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Sep 2002 20:29:46 -0400

>list and not the "change log for -05.txt" list.

How much of the playout model do you want to specify? The usual RTP semantic 
is that buffering is a local issue for the receiver, with the RTP timestamp
representing the timeline at the sender. You could make the sender aware of
the buffering at all receivers, but that would add significant complexity,
which may not be worthwhile.

>application, rather than add "dual-latency" features to the MWPP spec.

Multiple streams would seem to be the correct approach here, especially
since the usual RTP synchronisation mechanisms will take care of the dual
latency requirement. 

>streams in a finer-grained way, to ensure unambiguous semantics.

Seems reasonable, although I'm hardly a MIDI expert.

Cheers,
Colin

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 30 Sep 2002 07:27:20 -0400

It would seem that the "panic" function would be better handled by an 
out-of-band signal and then resychronization of the RTP media.

This same funcion is needed for barge-in control in ASR systems and rapid 
termination of streaming media playout using VCR-like controls when large 
jitter buffers are used at the receiver. Therefore, solving this on a 
per-media-format basis would be highly suboptimal.

The Speech Service Control WG has requirements in both of these areas (see 
draft-ietf-speechsc-reqts-00.txt).

My personal perferred machinery would be via RTCP by defining something 
like a new RTCP packet which asks the receiver to "dump your jitter buffer 
and ignore all data (e.g. in-flight packets) until timestamp T".

Dave.

--On Sunday, September 29, 2002 8:29 PM -0400 Colin Perkins 
<[email-masked]> wrote:

> How much of the playout model do you want to specify? The usual RTP
> semantic  is that buffering is a local issue for the receiver, with the
> RTP timestamp representing the timeline at the sender. You could make the
> sender aware of the buffering at all receivers, but that would add
> significant complexity, which may not be worthwhile.
>

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Sep 2002 09:38:05 -0400

You'd have to use the AVFP profile, presumably, to allow the immediate
feedback?
Colin