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

[Jean-Marc Valin]

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