[AVT] Re: Comments (1) on draft-ietf-avt-mwpp-midi-rtp-02.txt

[Dominique Fober <[e-mail]>]

Thanks for your reply. Some points are now more clear, but I have additional comments and questions:

>> Dominique Fober writes:
>>
>> I'm not convinced by the usefulness of interleaving MIDI commands into
>> SysEx segments.  [...] But maybe you have in mind some other use that I
>> don't see.

> John Lazzaro writes:
>
>This feature seems to be getting a fair amount of negative feedback,
>maybe its best for it to be deleted. Here's an explanation of why its
>there, let me know what you think of my justification ...

You're certainly right concerning interleaving with your example however,  my feeling is that the transmission speed on alternate physical layers allow to obtain the same result without interleaving. Lets take the example of an Ethernet 10Mb network: you can transmit 1Kb in less than 1 ms. In your example, and to justify interleaving, transmitted sysex size should be greater than 1kb to interfere with notes playing. Moreover, we may consider that Ethernet 100Mb is now very widespread.

>> Dominique Fober writes:
>>
>> First : what's the time status of such a MIDI command?  I guess that
>> its delta time is equal to the container SysEx delta time. 
>
> John Lazzaro writes:
>
>Yes, if you break up a SysEx command into three segments, the three
>delta times pin down the timing of the first octet of each segment.
>In the case of "pwe=1", these delta-times must be chosen so that you
>can fit the number of octets in each segment onto the MIDI cable
>(along with any System Realtime commands coded between the segments).
>Whereas, a "pwe=0" is under no such requirement, since its designed
>for situations where MIDI command transport and execution "in
>parallel" is encouraged.

One point was not really clear to me up to now and reading your reply and rereading the draft, I deduce that in the case of "pwe=1", delta-times should be adjusted by the sender to "real-time transmission" and in particular, a zero delta time is forbidden as commands are serialized on the MIDI wire.
I'm wondering about the usefulness and even the semantic of such time stamping: actually, as MIDI bytes are queued on the MIDI wire, conversion from a zero delta time to 'n' usec will be done naturally. Moreover, it seems to me that this mechanism operates most of the time as only the beginning of the command if time stamped: for example with a large sysex, only the transmission time of the first byte is specified and the remaining bytes are queued to be transmitted as fast as possible.
It also seems to me that it results in an ambiguity: lets say that you are regularly transmitting a 250 bytes sysex every 80 ms. In fact, 80 ms is the time required to transmit the command on the MIDI wire. A receiver won't be able to decide wether the sender intention was to send the commands as fast as allowed by MIDI or to indicates a 80 ms delay between them, which is different as soon as one wants to make time transformations for example.

Another point is that MIDI rate indicates clearly a 320 usec delay between 2 transmitted bytes but how to precislely code this delay when time is expressed in various rates specified by the SDP rtpmap. For example: with a 44100 (Hz) srate, one MIDI byte corresponds to 14,112 time units (15,36 for 48000). 

Lets take a last example concerning these timing issues: suppose a 24 bytes sysex with a dropped F7 and a 44100 (Hz) srate. In the case of "pwe=1", the next command delta time should be 338,688. If it's rounded to the nearest value (339), again the receiver won't be able to decide wether it means a dropped F7 or an intentional delay. To avoid this ambiguity, delta time should be rounded to its integer value (338).

My general feeling is that the semantic of delta time is a little bit complex in  pwe mode. Wouldn't it be possible to use delta time for the unique purpose of expressing the sender timing intention (maybe it's a fantasy). Of course it means that an additional mechanism to code the dropped F7 is to be provided (terminating the sysex with 2 consecutive F7 for example).

>
>> Dominique Fober writes:
>>
>>>4. Sender Addendum: Guard Packets
>
>>I understand that guard packets policy is implementation dependant and
>>that normative recommendations has been removed. However, apart of the
>>resiliency goal mentionned in <draft-lazzaro-avt-mwpp-midi-nmp-00.txt>,
>>guard packets may also be used to ensure that the receiver may compensate
>>its clock skew with a good accuracy. In this case, the receiver has to
>>receive packets at a minimum rate.
>
>>Don't you think that it would be usefull to keep recommendations about
>>guards packets at least within the appendix ?
>
> John Lazzaro writes:
>
>Another good point, I had not considered the clock skew issues here.
>Options would seem to including (1) adding to the main memo with a
>"recommended" (2) adding an SDP method to request a skew-sensitive
>sending procedure, or (3) adding it an Informational RFC which covers
>sending and receiving algorithms in detail, which clearly needs to be
>written as a companion to the normative memo ... I tend to lean
>towards (3), but maybe there's a good reason for (1) and (2) instead.

(3) is certainly a good solution but (2) is a more flexible one: it allows a receiver to request a (skew-)sensitive sending procedure and let the purpose of this procedure apart.

----------------------------------------------
Dominique Fober               <[e-mail]>
----------------------------------------------
GRAME - Centre National de Creation Musicale -
9 rue du Garet  69001 Lyon France
tel:[phone] fax:[phone]
http://www.grame.fr



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt