[Speex-dev] Jitter Buffer fix for frozen sender

[Thorvald Natvig]

The jitter buffer would "freeze" under the following condition:

- The sender and receiver are in sync.
- The sender machine freezes for a few seconds while the receiver does not.
- This causes all the packets sent by the sender to have a timestamp 
that is too low to be considered, meaning jitter_buffer_put ditches it 
before it checks if lost_count > 20 to reset.
- The jitter buffer will never reset on its own and will discard all 
incoming packets.

The patch moves the check for lost_count > 20 before the check if the 
packet is "hopelessly late". If lost_count > 20, something is very wrong 
and we want this packet to be the start of our new synchronized stream.

Also included is a testcase.

Note that I found a related problem if the receiver is frozen. Once it 
unfreezes, you may have a hundred speex_jitter_put before a _get. _get 
will then still return the very first packet, even if there are suddenly 
100 unplayed packets in the buffer (so it's playing old data). 
Similarily, if more than 300 packets are suddenly inserted, the buffer 
is full, and the call to _get actually fails, even if there are 300 
consecutive packets in the buffer. After a few _get calls, the buffer 
will reset, and the next packet inserted will be in sync again.
However, this is a rather unusual case, and the jitter buffer does 
recover from it, so I do not consider it critical.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: speex-jitter-frozen-sender.patch
Type: text/x-diff
Size: 3703 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20080409/6c611368/attachment.patch