Jean Marc, I don't think that the stack is getting corrupted- but I can't rule it out- so what I will do is try to record some samples to a file to reproduce this outside of the app. Is there a standard place to post test files? Note also I am intentionally stressing out speex here in part to figure out what the issue is- 99.9% of the time this issue never happens but right now it is not possible to recover from it when it does. The input to the LPC code is valid as far as I can tell, if a little large. The specific test case is that when a CPU gets spiked to 100% (which can happen) the audio captured can end up not being contiguous - ie. you'll have a set of samples then a gap and then another set of samples. So what usually happens is speex will (correctly) generate a large pop in its decoded audio and then go on its merry way. Some of the time, however, the decoder gets in a bad state- and then the decoded audio is always silent after an initial pop sound. Thanks again for your help! Tom
> I don't think that the stack is getting corrupted- but I can't > rule it out- so what I will do is try to record some > samples to a file to reproduce this outside of the app. > Is there a standard place to post test files?It would indeed be much easier to deal with a stand-alone file. If possible, please upload it to a website and send the URL. Otherwise, just send it to me privately (the list has a limit of 40 kB or so).> Note also I am intentionally stressing out speex here in > part to figure out what the issue is- 99.9% of the time > this issue never happens but right now it is not possible > to recover from it when it does.Well, it should definitely work 100% of the time.> The input to the LPC code is valid as far as I can tell, > if a little large.What do you mean large? The input to lsp_to_lpc should be between 0 and pi in the floating-point version.> The specific test case is that when a CPU gets spiked to > 100% (which can happen) the audio captured can end > up not being contiguous - ie. you'll have a set of samples > then a gap and then another set of samples. So what > usually happens is speex will (correctly) generate a large > pop in its decoded audio and then go on its merry way.Well, better to avoid these situations, although they shouldn't be affecting Speex.> Some of the time, however, the decoder gets in a bad > state- and then the decoded audio is always silent after > an initial pop sound.So you're telling me that the problem only occurs when there's a gap (overrun) on the encoder side? Jean-Marc
Jean Marc, So after creating stand alone decoder and encoder files, and running them through speexenc and speexdec, and using sse and non-sse versions of the code, the verdict is.... stack corruption. You were completely correct- The problem in this case is that the interp code was called in an unsafe manner such that it could be using the speex state at the same time as a standard decode. I wanted to post to the list so that others will know that there isn't an issue, and hopefully learn from my (bad) example of how (not) to post a bug report. Thanks again for your help! Tom