[Speex-dev] Speex on windows, audio cutting out ("bug" discussion and fixes)
kelly at peerium.com
Mon Feb 9 13:20:40 PST 2009
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
- 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 :))
More information about the Speex-dev