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

[Kelly Heffner]

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