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

[Petr Kuba]

Hi Simon,

Thanks for response.

Your explanation confirms my expectations. However, it doesn't seem to 
work in my case.

Am I correct that the "small adaptations" are made by modifications of 
timetamps in received packets? That's how I understand the source code.

I know that in my case the clockrate is not exactly 8000. That's why I 
need the adaptive jitter buffer. My problem is that even after the 
adaptations done by the jitter buffer the packet timestamps do not 
correspond to my local time which causes buffer overflow after some 
time. You can see this in the example in my previous email below.

Shouldn't the jitter buffer adapt the timestamps so that they correspond 
(more or less) to the local time (i.e. time of the receiving machine? 
Otherwise, how can I know when to play a packet or when to drop some?

Thanks,
Petr

On 15.3.2010 12:02, Simon Morlat wrote:
> 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