Re: [Linphone-developers] ortp: jitter buffer timestamp correction problem

[Simon Morlat]

Hi,

The purpose of the 'adaptive' jitter buffer is to take in account the
fact that different devices or machines are not synchronised. During a
long call there might be several milliseconds difference.
The receiver adapts to the clockrate of the sender using the adaptive
jitter buffer. The way it works is by computing a mean of the difference
between local timestamps and remote received timestamps. When this
difference tends to increase or decrease, small adaptations are made,
which results in discarding one or more packets, or skip one or more
packet (that will be delivered a bit later, thus corresponding to a
silence if the result is played to a soundcard).
The 324ms observation probably corresponds to something that really
happened on the audio streams. You can check the clockrate by doing
(last_ts - first_ts)/(last_packet_time-first_packet_time), using a
wireshark capture. In many cases you will see it is not exactly 8000,
while it was really 8000 at the sender side.

Hope this helps.

Simon


Le vendredi 05 mars 2010 à 17:04 +0100, Petr Kuba a écrit :
> Hi all,
> 
> could someone (probably Simon?) explain me how the "corrective_slide" 
> and timestamp correction mechanism in ortp works?
> 
> My idea was that the goal of this mechanism is to make the incoming 
> stream timestamps correspond to the local time. Am I right?
> 
> However, I'm experiencing the following situation. I use ortp with 
> adaptive jitter buffer and then I compare two packets of the same 
> incoming stream (values provided by ortp):
> 
> 1) ts=2529404960, seq=22032, ssrc=0xd1824425
> received at time 54652488 ms
> 
> 2) ts=2534100160, seq=51371, ssrc=0xd1824425
> received at time 55239064 ms
> 
> I'm using ulaw audio format where packets has 160bytes, which means 20ms.
> 
> And now:
> - the difference between the times these packets were received is 586576 
> ms. This corresponds to 29329 packets.
> 
> - we received 29339 packets (seq difference)
> 
> - the difference between the timestamps is 4695200. This corresponds to 
> 586900 ms, i.e. 29345 packets. Note that the timestamp values are 
> modified by the ortp adaptive jitter buffer.
> 
> I would expect the timestamp difference to correspond to the delivery 
> time difference but it seems to represent 586900 - 586576 = 324ms more. 
> So it looks like after 586576 ms of audio we received 324ms more than we 
> should. This causes us serious problems in synchronization of streams.
> 
> Do I miss something or is there anything wrong?
> 
> Thanks for help,
> Petr Kuba
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers