search for: float_div32

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

...> able to fit it in the production build without some trimming. > > > > Yes, there may be a bit of memory reduction possible here. Of course, > > decreasing the tail length is also a rather easy way. > > > >> 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 > > > > I think that was menti...

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

> 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

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

...il length = 1024), and I will probably not be > able to fit it in the production build without some trimming. Yes, there may be a bit of memory reduction possible here. Of course, decreasing the tail length is also a rather easy way. > 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 I think that was mentioned in the previous thread... >...

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

...bly not >> be >> able to fit it in the production build without some trimming. > > Yes, there may be a bit of memory reduction possible here. Of course, > decreasing the tail length is also a rather easy way. > >> 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 > > I think that was mentioned in the previous thre...

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

...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 : > &...

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

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