Speex dev - Oct 2005 - Changing the meaning of jitter buffer timestamp

Hi everyone,

I just changed the meaning of the timestamp in the jitter buffer. If you
don't know what I'm talking about, then you're not affected. If you
do
use the jitter buffer, than you will need to change your code
accordingly, so instead of bumping the timestamp by 20 (ms) for each
frame, you'll have to increase by 160 (samples) for narrowband or 320
for wideband. The new meaning should be closer to what RTP does (and not
have fractional value for sample rates like 44.1 kHz).

	Jean-Marc

On Saturday 01 October 2005 09:19, Jean-Marc Valin
wrote:
> I just changed the meaning of the timestamp in the jitter buffer. If you
> don't know what I'm talking about, then you're not affected. If
you do
> use the jitter buffer, than you will need to change your code
> accordingly, so instead of bumping the timestamp by 20 (ms) for each
> frame, you'll have to increase by 160 (samples) for narrowband or 320
> for wideband. The new meaning should be closer to what RTP does (and not
> have fractional value for sample rates like 44.1 kHz).
Hi,

what happens if this number flows over? It is just a "int", so it
might reach
its limits at 2^15 = 32768, that happens after 102 puts...In my current 
implementation I do "((long)packetCounter * 20) % 32760", but speex
doesn't
like me starting over at zero, and resets the buffer (every 32 seconds)...How 
to do it right?

Peter
-- 
The absent ones are always at fault.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20051005/876b5605/attachment.pgp

> what happens if this number flows over? It is just a "int", so it
might reach
> its limits at 2^15 = 32768, that happens after 102 puts...
I would say that an int is 32 bits :-) Actually, RTP defines the
timestamp as a 32-bit value. Now, what happens when it overflows (3 days
for narrowband), I don't know what the RFC says about it.
> In my current 
> implementation I do "((long)packetCounter * 20) % 32760", but
speex doesn't
> like me starting over at zero, and resets the buffer (every 32
seconds)...How
> to do it right?
Why do you insist on having considering only 16 bits?

	Jean-Marc