[Speex-dev] Speex on windows, audio cutting out ("bug" discussion and fixes)
kelly at peerium.com
Tue Feb 10 09:53:49 PST 2009
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.
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.
>> 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
>>> 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
>> _______________________________________________ Speex-dev mailing
>> list Speex-dev at xiph.org
More information about the Speex-dev