Speex dev - Feb 2009 - Speex on windows, audio cutting out ("bug" discussion and fixes)

David Hogan a ?crit :
> Are you calling the speex API from multiple threads?
> 
> If so, I suspect that if you use a mutex to ensure that only one
> thread can access the speex API at a given moment, the problem will
> go away. Obviously this reduces the scalability of your program, but
> it makes a good test. If that fixes it, then I recommend changing the
> code to ensure that only one thread at a time can call speex API
> functions on a given preprocessor/encoding/decoding state.
Just to clarify things, you can call the Speex API functions from
multiple threads without using any mutex. What you *cannot* do is to use
the *same state* from multiple threads without using a mutex.

	Jean-Marc

> Cheers, Dave
> 
> David Hogan Handset Team Leader
> 
> Freshtel R&D Pty Ltd Level 2, 95 Coventry Street Southbank  VIC 3205 
> Ph: +61 (0)3 9095 2000 Direct: +61 (0)3 9095 2003 Fax: +61 (0)3 9095
> 2099 FIP: 80994099 Web: www.freshtelholdings.com
> 
> Privacy & Confidentiality Notice The information contained in this
> email is intended for the named recipient only. It may contain
> privileged and confidential information and if you are not the
> intended recipient you must not copy distribute or take any action in
> reliance on it. This email and any file attached should be scanned
> for viruses. No liability is accepted for any loss or damage
> resulting from a computer virus or resulting from a defect in
> transmission of this email or any attached file. If you have received
> this email in error please notify us immediately by telephoning +613
> 9095 2000.
> 
> 
> 
>> -----Original Message----- From: speex-dev-bounces at xiph.org
>> [mailto:speex-dev-bounces at xiph.org] On Behalf Of Kelly Heffner 
>> Sent: Tuesday, 10 February 2009 8:21 AM To: speex-dev at xiph.org 
>> Subject: [Speex-dev] Speex on windows,audio cutting out
("bug"
>> discussion and fixes)
>> 
>> Hi everyone!
>> 
>> Our company is writing some voice chat software using Speex, and I
>> am in charge of writing the Windows-only portion of the code.  I've
>> just finished tracking down a very nasty little bug in our program,
>> and, I saw similar symptoms of the bug in one or two posts in the
>> list archives, so I thought I would make a new post in case anyone
>> runs across this again.
>> 
>> Symptom: While decoding and playing sound on windows, the sound 
>> "clicks" and then cuts out (or continues to make
"clicking"
>> noises). This happens after a random amount of time, sometimes
>> immediately, sometimes in the 30 seconds to 1 minute range, but
>> rarely much longer than a minute.  The windows audio system does
>> not appear to be starved of audio data to play.
>> 
>> Deeper problem: After some amount of time, the two values in the
>> high- pass filter buffer of the sound decoder become NaN.  The
>> decoded sound buffers all come out as a series of NaNs.
>> 
>> Building libspeex disabling floating-point computation fixes the 
>> problem, but is unsatisfying :)
>> 
>> In the course of debugging this I did find a (maybe) bug in the 
>> narrowband libspeex code.  The control message SPEEX_RESET_STATE to
>>  the decoder (I think) should reset the high-pass filter buffer to
>> zero.
>> 
>> We're actually using the speex library through foreign function
>> calls in Haskell (using ghc), which contributes to the decoding
>> glitch in two ways: - Our program is very concurrent, with many
>> lightweight threads being managed on top of OS threads.  The speex
>> library does seem to be holding up on that front :) but -- - The
>> windows pre-built ghc compiler is built with and older version of
>> gcc (3.4.2 mingw), and I was using that version of gcc to compile 
>> and link libspeex and everything up.
>> 
>> After eliminating other possibilities, we think the problem is that
>>  the older gcc has a small bug that causes some of the floating
>> point state to not be managed correctly in a multithreaded program,
>>  eventually sending the computation into NaN land.  I am in the
>> process of building everything back up with gcc-4 to verify this on
>> windows. We don't have this problem on the intel mac build, that
>> was already switched to gcc-4.
>> 
>> As amused as we are that I have found a bug that really might be 
>> caused by the compiler ;-) I'd also be open to other reasons that
>> the high-pass filter buffer is getting junked up.  However,
>> hopefully this post will help someone debugging this crazy problem
>> in the future -- and its an amusing story otherwise (at least I
>> hope so! and if not, I'm terribly sorry :))
>> 
>> ~Kelly _______________________________________________ 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 very much appreciate the help trying to find a more satisfying reason 
behind my bug :)

We do mutex access to each speex state, but we rely on the re-entrance 
of the API and do not mutex around all access to the API.

However, when I am only listening to one person (and therefore only have 
one speex state) I'm essentially mutexing the API :) and the high pass 
filter buffer goes to NaN.

~Kelly

Jean-Marc Valin wrote:
> David Hogan a ?crit :
>> Are you calling the speex API from multiple threads?
>>
>> If so, I suspect that if you use a mutex to ensure that only one
>> thread can access the speex API at a given moment, the problem will
>> go away. Obviously this reduces the scalability of your program, but
>> it makes a good test. If that fixes it, then I recommend changing the
>> code to ensure that only one thread at a time can call speex API
>> functions on a given preprocessor/encoding/decoding state.
> 
> Just to clarify things, you can call the Speex API functions from
> multiple threads without using any mutex. What you *cannot* do is to use
> the *same state* from multiple threads without using a mutex.
> 
> 	Jean-Marc
> 
> 
>> Cheers, Dave
>>
>> David Hogan Handset Team Leader
>>
>> Freshtel R&D Pty Ltd Level 2, 95 Coventry Street Southbank  VIC
3205
>> Ph: +61 (0)3 9095 2000 Direct: +61 (0)3 9095 2003 Fax: +61 (0)3 9095
>> 2099 FIP: 80994099 Web: www.freshtelholdings.com
>>
>> Privacy & Confidentiality Notice The information contained in this
>> email is intended for the named recipient only. It may contain
>> privileged and confidential information and if you are not the
>> intended recipient you must not copy distribute or take any action in
>> reliance on it. This email and any file attached should be scanned
>> for viruses. No liability is accepted for any loss or damage
>> resulting from a computer virus or resulting from a defect in
>> transmission of this email or any attached file. If you have received
>> this email in error please notify us immediately by telephoning +613
>> 9095 2000.
>>
>>
>>
>>> -----Original Message----- From: speex-dev-bounces at xiph.org
>>> [mailto:speex-dev-bounces at xiph.org] On Behalf Of Kelly Heffner 
>>> Sent: Tuesday, 10 February 2009 8:21 AM To: speex-dev at xiph.org 
>>> Subject: [Speex-dev] Speex on windows,audio cutting out
("bug"
>>> discussion and fixes)
>>>
>>> Hi everyone!
>>>
>>> Our company is writing some voice chat software using Speex, and I
>>> am in charge of writing the Windows-only portion of the code. 
I've
>>> just finished tracking down a very nasty little bug in our program,
>>> and, I saw similar symptoms of the bug in one or two posts in the
>>> list archives, so I thought I would make a new post in case anyone
>>> runs across this again.
>>>
>>> Symptom: While decoding and playing sound on windows, the sound 
>>> "clicks" and then cuts out (or continues to make
"clicking"
>>> noises). This happens after a random amount of time, sometimes
>>> immediately, sometimes in the 30 seconds to 1 minute range, but
>>> rarely much longer than a minute.  The windows audio system does
>>> not appear to be starved of audio data to play.
>>>
>>> Deeper problem: After some amount of time, the two values in the
>>> high- pass filter buffer of the sound decoder become NaN.  The
>>> decoded sound buffers all come out as a series of NaNs.
>>>
>>> Building libspeex disabling floating-point computation fixes the 
>>> problem, but is unsatisfying :)
>>>
>>> In the course of debugging this I did find a (maybe) bug in the 
>>> narrowband libspeex code.  The control message SPEEX_RESET_STATE to
>>>  the decoder (I think) should reset the high-pass filter buffer to
>>> zero.
>>>
>>> We're actually using the speex library through foreign function
>>> calls in Haskell (using ghc), which contributes to the decoding
>>> glitch in two ways: - Our program is very concurrent, with many
>>> lightweight threads being managed on top of OS threads.  The speex
>>> library does seem to be holding up on that front :) but -- - The
>>> windows pre-built ghc compiler is built with and older version of
>>> gcc (3.4.2 mingw), and I was using that version of gcc to compile 
>>> and link libspeex and everything up.
>>>
>>> After eliminating other possibilities, we think the problem is that
>>>  the older gcc has a small bug that causes some of the floating
>>> point state to not be managed correctly in a multithreaded program,
>>>  eventually sending the computation into NaN land.  I am in the
>>> process of building everything back up with gcc-4 to verify this on
>>> windows. We don't have this problem on the intel mac build,
that
>>> was already switched to gcc-4.
>>>
>>> As amused as we are that I have found a bug that really might be 
>>> caused by the compiler ;-) I'd also be open to other reasons
that
>>> the high-pass filter buffer is getting junked up.  However,
>>> hopefully this post will help someone debugging this crazy problem
>>> in the future -- and its an amusing story otherwise (at least I
>>> hope so! and if not, I'm terribly sorry :))
>>>
>>> ~Kelly _______________________________________________ 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
>>
>>
>

> We do mutex access to each speex state, but we rely on the re-entrance
> of the API and do not mutex around all access to the API.
> 
> However, when I am only listening to one person (and therefore only
have
> one speex state) I'm essentially mutexing the API :) and the high pass
> filter buffer goes to NaN.
Hi Kelly,

It's seems unlikely that the problem is with speex itself, as many other
people are able to decode speex audio without issue. We're using it on
Windows, OS X & iPhone OS in narrow and wideband modes, and additionally
on linux within Asterisk. Are you able to reproduce the issue with the
example speex programs? Perhaps there's a concurrency / initialization
issue on the encoding side, which produces a corrupt speex stream.

What sort of Mutex are you using ? I don't know what lightweight threads
are, but if they somehow all exist within one OS thread then they might
just recursively lock the same mutex instead of acually blocking.

Cheers,
Dave