Speex dev - Apr 2008 - newbie qs - can one implement speex for Google Android?

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
>

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