[Speex-dev] Changing the meaning of jitter buffer timestamp
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?
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
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