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

[David Hogan]

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