[Speex-dev] Jitter Buffer fix for frozen sender
thorvald at natvig.com
Wed Apr 9 03:55:48 PDT 2008
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
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...
Size: 3703 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20080409/6c611368/attachment.patch
More information about the Speex-dev