search for: weight_shift

...->W[j*N+i],16+NORMALIZE_SCALEDOWN)); spx_ifft(st->fft_table, st->wtmp2, st->wtmp); #else spx_ifft(st->fft_table, &st->W[j*N], st->wtmp); #endif for(i=0;i<n;i++) - filt[j*n+i] = PSHR32(MULT16_16(32767,st->wtmp[i]), WEIGHT_SHIFT); + filt[j*n+i] = PSHR32(MULT16_16(32767,st->wtmp[i]), WEIGHT_SHIFT-NORMALIZE_SCALEDOWN); } } break;

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

...i=0;i<N;i++) + st->wtmp2[i] = EXTRACT16(PSHR32(st->W[j*N+i],16)); + spx_ifft(st->fft_table, st->wtmp2, st->wtmp); +#else + spx_ifft(st->fft_table, &st->W[j*N], st->wtmp); +#endif + for(i=0;i<n;i++) + filt[j*n+i] = PSHR32(MULT16_16(32767,st->wtmp[i]), WEIGHT_SHIFT); + } + } + break; default: speex_warning_int("Unknown speex_echo_ctl request: ", request); return -1;

...y 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 side-by-side and look for differences. Can e really go to 0? I don...

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

Hi Ted, Thanks a lot for this analysis. > 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: True, that needs to be fixed even after I fix the rest. > leak_estimate =

...] = 0; + w[(i+1)*n-1] = 0; + for(j=1;j<n-1;j++) { + t1 = MULT16_16(SHR32(st->W[i*N+j*2],16), SHR32(st->W[i*N+j*2],15)); + t2 = MULT16_16(SHR32(st->W[i*N+j*2-1],16), SHR32(st->W[i*N+j*2-1],15)); + t3 = MULT16_16(100,spx_sqrt(ADD32(t1,t2))); + w[i*n+j] = SHR32(t3, WEIGHT_SHIFT); + } + } + } + break; default: speex_warning_int("Unknown speex_echo_ctl request: ", request); return -1; Index: libspeex/preprocess.c =================================================================== --- libspeex/preprocess.c (revision 14443) +++ libs...

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

...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've just been made aware of these problems (look for the thread &qu...

...oblem 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 side-by-side and look for differences. Can e really go to 0? I d...

...o > > 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 side-by-side and look for diff...