Speex dev - Feb 2009 - 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

Hi Kelly,

Sorry if I'm just stating the obvious, but ..

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.

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

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
> 
>