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

> 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

On Wednesday 05 October 2005 13:53, Jean-Marc Valin
wrote:
> > 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?
My C book taught me an int is only guaranteed to be 16bits or bigger, and 
since I am trying to write code that doesn't break on other systems, I am 
assuming the "worst case". Hence I have to deal with the overflow...
Is my
information that "int" can be 16bit (a) false or (b) true but not
valid for
any relevant architecture?

Quote from http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size

A short int must not be larger than an int.
An int must not be larger than a long int.
A short int must be at least 16 bits long.
A long int must be at least 32 bits long.

In my words:
16 bit <= short <= int <= long >= 32 bit

I know for a fact that my ints are 32bits long, but I am worried that it might 
not be the case everywhere, that is why I did the above modulus hack, to make 
sure overflowing works (which it doesn't, at least not without a jitter 
buffer reset and some aliens visiting).

Even with 32 bits, is 37 hours of audio transmition (wide band) something that 
one should consider not to happen?

Peter
-- 
Before borrowing money from a friend, decide which you need more.
		-- Addison H. Hallock
-------------- 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/441d6e12/attachment-0001.pgp

> My C book taught me an int is only guaranteed to be 16bits or bigger, and 
> since I am trying to write code that doesn't break on other systems, I
am
> assuming the "worst case". Hence I have to deal with the
overflow... Is my
> information that "int" can be 16bit (a) false or (b) true but not
valid for
> any relevant architecture?
c) assumes that I won't just change the call to say spx_int32_t instead
of "int" ;-) It was always meant to be 32 bits anyway.
> Even with 32 bits, is 37 hours of audio transmition (wide band) something
that
> one should consider not to happen?
I guess I should deal with it at some point, but I'd like to know what
the RTP RFC says first.

	Jean-Marc

Also, the initial value of the timestamp is supposed to be random, so it's
entirely possible you'll have the possibility of overflow in a short amount
of time.