Jean Marc-
Thanks for looking into this- I think I needed to give you a
bit more info! Sorry for such a vague initial report.
So most of these problems seem to be coming
from the lsp_to_lpc function. In particular the following:
xout1 = xin1 - 2.f*x_freq[i2] * *n1 + *n2;
xout2 = xin2 - 2.f*x_freq[i2+1] * *n3 + *n4;
... in the floating point version this code can produce xout1 or
xout2 that go to INF.
That is the main issue- I have also seen the IIR filter go wonky
occasionally, which is what is corrupting st->mem_sp. Usually
this is just because there are some odd values in st->interp_qlpc.
However it seems like it can also just happen sometimes as
output of the _mm_mul_ps multiply goes to INF (this can also
happen in the non-sse code). I am working on figuring out why
this is happening.
With the new changes also filter_ratio went to 0 in one of my
tests, in part because rh was INF. This is around the section
where I think you made changes to how you calculate st->pi_gain[sub].
This caused scale to go to INF further down in the code when
scale is calculated. Again, this I think stems from the lpc function
producing some INF and IND values so I think that is just a symptom.
I can add bounds checking to the SSE code but I don't know
what to do regarding the lpc code.
When this happens the easy fix is to just reset the upper band to
VERY_SMALL and also to reset mem_sp but I am hoping that this
won't be needed if the lpc values were in the right range.
Tom
At 07:29 AM 3/14/2007, you wrote:>While looking for the problem, I ended up fixing two other things that
>could be related. Can you test current svn and tell me if the problem
>still occurs? Is so, can you tell me exactly what options you've been
>using (sampling rate, bit-rate, vbr, vad, dtx, ...)?
> Thanks for looking into this- I think I needed to give you a > bit more info! Sorry for such a vague initial report. > > So most of these problems seem to be coming > from the lsp_to_lpc function. In particular the following: > xout1 = xin1 - 2.f*x_freq[i2] * *n1 + *n2; > xout2 = xin2 - 2.f*x_freq[i2+1] * *n3 + *n4; > > ... in the floating point version this code can produce xout1 or > xout2 that go to INF.Well, the question is where does the problem come from. To give INF on the output, there would need to be a problem with the input. Checked that?> That is the main issue- I have also seen the IIR filter go wonky > occasionally, which is what is corrupting st->mem_sp.Well, they would if the filter is bad (read unstable).> Usually > this is just because there are some odd values in st->interp_qlpc. > However it seems like it can also just happen sometimes as > output of the _mm_mul_ps multiply goes to INF (this can also > happen in the non-sse code). I am working on figuring out why > this is happening.Can you leave SSE out of that for now?> With the new changes also filter_ratio went to 0 in one of my > tests, in part because rh was INF. This is around the section > where I think you made changes to how you calculate st->pi_gain[sub]. > This caused scale to go to INF further down in the code when > scale is calculated. Again, this I think stems from the lpc function > producing some INF and IND values so I think that is just a symptom. > > I can add bounds checking to the SSE code but I don't know > what to do regarding the lpc code. > When this happens the easy fix is to just reset the upper band to > VERY_SMALL and also to reset mem_sp but I am hoping that this > won't be needed if the lpc values were in the right range.Bounds checking and resets aren't the way to go. Fixing the source of the problem is. Did you actually test with speexenc/speexdec BTW. I'm beginning to suspect you're writing an application that simply corrupts the Speex state/stack and causes it do to all kinds of strange things. Jean-Marc
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