search for: must_iterate

...*x, spx_sig_t max_scale, int len) { int sig_shift_ti=32; int i; #warn Using the optimized norm_shift() function. /* TI Specific. */ #if (0) assert((len>=24)&&(len<=184)); // Check MUST_ITERATE() range. assert(0 == (len&0x03)); // Can help compiler if length is multiple of 4. _nassert((len>=24)&&(len<=184)); // Check MUST_ITERATE() range. _nassert(0 == (len&0x03)); // Length must be multiple of 4....

You might not be doing anything wrong. Speex is stateful and can get into a bad state sometimes. It's happened to me too, but not recently. And I've seen such bugs reported on this list and fixed. I suggest several approaches to solving the problem: 1) Try compiling Speex without compiler optimizations and see if the problem still occurs. Most likely it will, but this is an

...6384). */ static inline int norm_shift(const spx_sig_t *x, spx_sig_t max_scale, int len) { int sig_shift_ti; int i; #warn Using the optimized normalize16() function. /* Directly find the min(_norm(x[i]) rather than searching for max(abs(x[i])) and taking _norm. */ #pragma MUST_ITERATE(24,184,4) for (i=0;i<len;i++) { sig_shift_ti=min(sig_shift_ti,_norm(x[i])); } sig_shift_ti=max(0,_norm(max_scale-1)-sig_shift_ti); /* Return the shift value. */ return(sig_shift_ti); } // norm_shift(). PS. Here are the C64x MIPS vs Complexity resu...

Hi, Basically, inner_prod() can and should be adapted to the architecture it will run on. It is not really sensitive to noise, so it's possible to tweak it a lot. Also, in the current code, I saturate it to +-16384, which is OK to prevent overflows. I'm not concerned with the case of a constant -16384 value because it can't really happen in practice (especially after filtering). BTW,