search for: float_shl

...ollowing: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); > where st->Pey and st->Pyy are both zero, which happens for the following input > data to testecho program: > -- first arg is file containing sine wave of magnitude +/- 32767 > -- 2nd arg is file containing all zeroes > > The divis...

...gt; 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 n...

> I am writing to gain a better understanding of the limitations of speex echo > cancellation, esp. with respect to the fixed point implementation. > If these limitations have been documented elsewhere already, please let me > know! Nothing officially documented, sorry. > I observe experimentally that when one or both of the echo or ref data for > speex_echo_cancel() have

...ion in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: > 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); Actually, I just found a 16-bit bug in FLOAT_DIV32_FLOAT. Could you update svn and let me know if it works? > and it is e that is in the denominator, not r (sorry for the confusion). I > can now r...

...(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 instrumen...

Just tried your files and I'm not running into any infinite loops and the cancellation works fine. Unless the C6x has the same problem, I suspect a 16-bit problem. I'll check and see if I find something. About the r=0 problem, I can't find where it ends up in a denominator, so I suspect is not (directly) the problem. Jean-Marc Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?crit

Thanks for your prompt and helpful reply. In FLOAT_DIVU() it hangs at the following: while (a.m >= b.m) { e++; a.m >>= 1; } for the case where a and b are both zero (yes, division by zero). This happens from mdf.c: leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); where st->Pey and st->Pyy are both zero, which happens for the following input data to testecho program: -- first arg is file containing sine wave of magnitude +/- 32767 -- 2nd arg is file containing all zeroes The division by zero appears to be caus...

...the TI C64 simulator, and the echo was canceled nicely (about 10:1 reduction in the peak amplitude during the second of two brief speech bursts). So, my problem must again be related to the 16-bit processing on the C5X DSPs. Also, the line where it is hanging is: 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); and it is e that is in the denominator, not r (sorry for the confusion). I can now run the simulations side-by-side and look for differences. - Jim Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?c...

...in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related > to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: > 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); Actually, I just found a 16-bit bug in FLOAT_DIV32_FLOAT. Could you update svn and let me know if it works? > and it is e that is in the denominator, not r (sorry for the confusion). > I > can n...

...econd of two brief speech bursts). So, my problem must again be related > > to > > the 16-bit processing on the C5X DSPs. > > Good. At least we've narrowed it down a bit. > > > Also, the line where it is hanging is: > > 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); > > Actually, I just found a 16-bit bug in FLOAT_DIV32_FLOAT. Could you > update svn and let me know if it works? > > > and it is e that is in the denominator, not r (sorry for the confu...