[Speex-dev] Changing the meaning of jitter buffer timestamp

Peter Kirk pwk.linuxfan at gmx.de
Wed Oct 5 06:17:09 PDT 2005


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


More information about the Speex-dev mailing list