>> >> Therefore, a mecanism to compensate for the latency variation seems to >> me to be necessary. >> > >I don't think its always necessary -- MWPP should provide the freedom >to implement latency variation compensation, but I don't think it >should mandate it. In our experience playing over the CalREN 2 >Berkeley-Stanford and Berkeley-Caltech links, jitter compensation >wasn't necessary; "play when received" worked well, as long as the >"outliers" of very late packets were handled separately, using >semantic rules (which is what the "ontime" and "late" flags codify). >
I agree: MWPP may let the compensation task to the client responsability, provided that the client get the necessary information to do so. Are RTP timestamped packets enough ? I'm not sure: dealing with time on different stations may rapidly reach the problem of clock skew. Lets take an example in http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf appendix B which is refered in draft-lazzaro-avt-mwpp-midi-nmp-00 section 3: the model of time is based on what I call the apparent clock offset (ACO) ie the clock offset between the sender and the receiver + the current transport latency at the time of the measurement (tf minus t0). Deciding wether a packet is "on time" or "late" is based on the latency variation which is evaluated as the current ACO minus the initial ACO. But if the receiver clock is running faster than the sender clock, the latency will appear as constantly increasing and will reach 'maxlate' sooner or later, triggering a set of 'late packets' up to the 'late window' exhaustion (3.5 s). Of course, the clock skew depends on the clocks used to timestamp the packets and to collect the current time on receiver side. My experience of software clocks (based for example on timer tasks) is that you can get significant drift: for example 1 ms per 10 sec which means that maxlate is then reached in about 6 mn. I don't want to claim that it's a real problem: using more acurate clocks may solve the problem for a given time. However, fixing the limits (the skew tolerance and the corresponding time limit) would be useful for the protocol implementation. --df ---------------------------------------------- Dominique Fober <[EMAIL PROTECTED]> ---------------------------------------------- GRAME - Centre National de Creation Musicale - 9 rue du Garet 69001 Lyon France tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01 http://www.grame.fr
