Speex dev - Mar 2007 - re: decoder issue in sb_celp

A little more info on this:

I backtracked deeper into this and it looks like excBuf
is corrupted, which is corrupted by low_innov_alias
being invalid.  However it is not entirely clear where
that gets initialized (in sb_celp it is set to out+st->frame_size)

Tom

I'll look into this. I've made a lot of changes to that code recently,
so it's quite possible I broke something. If you happen to find when I
broke it (1.2beta1 works OK, right), please let me know. Any other info
would be useful as well (e.g. test sample, more info from debugging, ...)

	Jean-Marc

Tom Harper a ?crit :
> A little more info on this:
> 
> I backtracked deeper into this and it looks like excBuf
> is corrupted, which is corrupted by low_innov_alias
> being invalid.  However it is not entirely clear where
> that gets initialized (in sb_celp it is set to out+st->frame_size)
> 
> Tom
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
> 
>

Tom Harper a ?crit :
> A little more info on this:
> 
> I backtracked deeper into this and it looks like excBuf
> is corrupted, which is corrupted by low_innov_alias
> being invalid.  However it is not entirely clear where
> that gets initialized (in sb_celp it is set to out+st->frame_size)
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, ...)?

	Jean-Marc

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, ...)?