[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] Re: [MMUSIC] maxptime




On Oct 22, 2004, at 5:55 AM, Magnus Westerlund wrote:
I think I understand this, however the RTP timestamp rate
as I understand it for MIDI would be equal to the sample rate for the audio produced?

Yes -- for best results, the MIDI timestamp resolution should equal the audio sampling rate (44.1, 48, 96, or 192 KHz).

However I do hope that a sender at least correctly timestamp the RTP packets sent.
Thus the RTP receiver can in the future start using the timing model correctly.

Sender time stamping is a MUST.

In conclusion I would suggest that you use another MIME parameter than
ptime and maxptime to indicate the desired behavior.

OK, I'll redo this part of the I-D, and create new MIME parameters
to partially convey what the I-D previously coded using ptime and maxptime.


Unless a miracle happens, I won't make the Monday deadline with
a new I-D pair ... so it will have to wait post-D.C. But I really hope we can
make it to Last Call for the two I-Ds by the holidays ...


I also think that the format drafts needs to be more explicit on considerations for the RTP timestamp. What rates are suitable, what are the impact on playback timing. There seems to be a bit on this in the guidelines, but I haven't had time to read it fully.

See C.6.3 in the normative I-D. Part of Appendix C.6, the "SDP Interoperability Section", it might be easier to read all of C.6.

Also, in the guide I-D, Section 4 discusses sender timing,
Section 6 discusses receiver timing.

No, I am not questioning this timing model at all. It seems appropriate
for RTP based on your description.

Great -- thinking it over last night, I'm pretty sure that if I was forced
to define the media time for a packet with a single MIDI command
whose command timestamp equals the RTP timestamp to be 1 RTP
timestamp tick long (and not 0 ticks as it is now), the recovery journal
would break.


---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---


_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt