[Speex-dev] Speex echo canceller on TI C55 DSP

[Jim Crichton]

Jean-Marc,

I have traced the second infinite loop further.  When st->adapted becomes 
true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 
0xd4e, the resulting r is 3.  The first value in st->Rf is 0, so e is 1, and 
r is set to e>>1, or 0.  A little later there is a divide by r, and there is 
the hang.

It seems that the 0 in Rf[0] is the problem, but I am not sure what else to 
look at there.  The first few 32-bit values in Rf are:

0 0 1 1 0 2 D D 5 0 8 11 19 3D 51 74 3A 8 11 8 4

Do you have any suggestions?

- Jim

----- Original Message ----- 
From: "Jim Crichton" <jim.crichton at comcast.net>
To: <speex-dev at xiph.org>
Sent: Monday, May 08, 2006 12:11 PM
Subject: [Speex-dev] Speex echo canceller on TI C55 DSP


> Jean-Marc,
>
> I recently started looking at running the echo canceller on a TI C55 DSP 
> along with the 8kbps narrowband Speex encoder/decoder.  This is one of 
> those "braindead compilers" that you refer to from time to time, and 
> cannot handle the float struct assignments in the return statements in 
> pseudofloat.h.
>
> Most of these were eliminated in build 11311 (patch by Brian Retford), but 
> there were four left that I had to break apart.  I started with build 
> 11343.
>
> I got several compiler warnings for "shift out of range" in mdf.c, which I 
> fixed by adding EXTEND32 to all of the SHL32s with 16 bit operands 
> (st->frame_size in 6 places, st->wtmp2 in 1 place).  I have not sent 
> patches for these two changes, because I still have other problems.
>
> If fftwrap.c, I ifdefed out the spx_fft_float and spx_ifft_float routines, 
> because there were not used and required smallft.c (which is not so small 
> at all) to be added to the build.
>
> With these changes, the link was successful, using testecho.c with some 
> modifications for the C55 environment.  The code and data memory 
> requirements were a lot more than I had hoped (>20kbytes of dynamic data 
> memory for block size=128, tail length = 1024), and I will probably not be 
> able to fit it in the production build without some trimming.
>
> When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c 
> line 660), which occurs because adapt_rate is < 0, which happens when 
> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}.  The rounding is causing 
> the result to go negative.  I worked around this by changing
>
>      return (a.m+(1<<(-a.e-1)))>>-a.e;
> to
>      return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e;
>
> in FLOAT_EXTRACT16.  This changes the returned value from 0xfc00 to 0x400. 
> Now it runs on for a while, then hits another infinite loop at mdf.c line 
> 641:
>
>         st->power_1[i] = 
> FLOAT_SHL(FLOAT_DIV32_FLOAT(MULT16_32_Q15(M_1,r),FLOAT_MUL32U(e,st->power[i]+10)),WEIGHT_SHIFT+16);
>
> I have not had time to trace this, but it looks like a similar problem, 
> where the result of MULT16_32_Q15(M_1,r) is negative, and 
> FLOAT_DIV32_FLOAT bombs.  Maybe the best thing to do next is to instrument 
> the routines in pseudofloat.h which have loops, but I will not get to that 
> for a day or two.
>
> I need to make a decision soon whether to seriously pursue making this 
> work. With that in mind, here are some questions:
>
> 1.  speex_echo_state_init takes about 20M instructions, which is a little 
> frightening, and the calls to speex_echo_cancel take about 630K 
> instructions for 128 samples.  Given your recent experience with the fixed 
> point canceller, does this sound rational?  The MIPs for the canceller are 
> similar to the MIPs for the encoder running 8kbps, complexity 1.
>
> 2.  The testecho example uses a frame length and tail size that are powers 
> of two (128, 1024).  Are there any implications to using sizes which are 
> not powers of two?  It would be most convenient to use the encoder frame 
> size (160), and some multiple of that for the tail size.  How does the 
> frame size affect performance (I understand that the tail length 
> determines what echo signals are cancelable)?
>
> 3.  Do you have any suggestions for code/data memory reduction for the 
> canceller, other than to make the tail length no longer than necessary 
> (this is a line echo canceller for a local phone, so I should be able to 
> keep it to 40ms).  I was surprised by the size of the FFT code, but I 
> guess that it is doing much more than the radix2 version in the TI 
> library.
>
> Regards,
>
> Jim Crichton
>
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>