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
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
Hi. On substandard hardware (read: "cheapest possible" commodity stuff) installed on a fairly popular OS, but without any updated drivers, the machine will frequently freeze in kernel mode for 100-200ms. It will infrequently freeze in kernel mode for 2-3 seconds. The users, for some reason unknown to me, accept this as quite common on PCs. So the frequency of the problem is inversely proportional to the computer savvy of the user. As for how to fix it, I'm not really sure. Perhaps an idea would be to add a ctl to indicate "I might have frozen; I'm going to need 80 ms of data in total to refill my buffers, please update accordingly."? The problem with that though is that once you unfreeze, you don't know if it's the audio output thread or your network thread that gets called first. There's an alternate idea; instead of discarding late packets etc, insert them too into the jitter buffer, and discard the packets with the lowest sequence instead of the lowest timestamp. Then, at any time the user calls _get, if there are more "useless" packets in the buffer then "usefull" ones, scan for the longest semi-continous sequence and switch. This will also allow the jitter buffer to quickly adapt to timestamp rollover, freezes at either end and most other oddities I can think of. It is computationally complex though, and a rather drastic change. .. Perhaps something for the 1.3 timeframe? Jean-Marc Valin wrote:> 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 >> > > _______________________________________________ > Speex-dev mailing list > Speex-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >
Anil Philip
2008-Apr-11 21:58 UTC
[Speex-dev] newbie qs - can one implement speex for Google Android?
I recommended in a bug report that the new mobile platform - Android should use speex and it was accepted. I was wondering if I can use it as a 3rd party library even now. Can someone please tell me how? The JSpeex project has had no activity for almost 3 years and questions are unanswered. the android post is here http://groups.google.com/group/android-developers/browse_thread/thread/3b0502315aad75c1# __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20080411/0e370557/attachment.htm