[Speex-dev] Jitter Buffer fix for frozen sender

[Jean-Marc Valin]

Patch applied offline (I'm in the plane), remind me if I forget to push
it. About the "resync on burst" issue, I was aware of it, but I'm not
sure how to fix it. Any idea? Also, do you see the problem happening often?

	Jean-Marc

Thorvald Natvig a écrit :
> 
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev