search for: float_div32_float

...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 run the simulations...

...alue 0x8000 is avoided in the input. I think we can safely assume that -- or actually enforce that because it would likely break other stuff. > Even with this fix there is definitely some bad stuff going on; the output > data is corrupted looking. > I put assertions into FLOAT_MUL32U(), FLOAT_DIV32_FLOAT() and FLOAT_DIV32() to > assert that the "a" arguments were non-negative. Technically these functions *should* work (they don't at the moment) for negative inputs, but mdf.c isn't supposed to use that in the first place. I guess it comes down to the same problem as above......

...es the value to exactly 0x8000, and it is followed by a > right shift, so you just need to avoid the sign extension. > > >> 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. > > > > Yeah, r is never supposed to be negative and the float routines assume > > that....

...; 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 instrume...

...ak 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 run the simulat...

...t;<(-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...

...4 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 ?crit : > > I&...

...wo 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 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

...gt;>-a.e; > to > return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; Is that sufficient to remove all the overflows at this place? > 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. Yeah, r is never supposed to be negative and the float routines assume that. > 1. speex_echo_state_init takes about 20M instruction...

...place? The rounding takes the value to exactly 0x8000, and it is followed by a right shift, so you just need to avoid the sign extension. >> 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. > > Yeah, r is never supposed to be negative and the float routines assume > that. No, it was a divide by zero,...

...x++ * *y++)>>1); part = part + ((*x++ * *y++)>>1); sum += part>>5; I am assuming that the value 0x8000 is avoided in the input. Even with this fix there is definitely some bad stuff going on; the output data is corrupted looking. I put assertions into FLOAT_MUL32U(), FLOAT_DIV32_FLOAT() and FLOAT_DIV32() to assert that the "a" arguments were non-negative. Using some real life data, i found that i had to shift the real life data right by two (i shifted both inputs by same amount) to avoid asserting; shifting by just one almost worked but failed for some case (i don&...