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

[Kelly Heffner]

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