search for: sig_shift_ti

...an also be used twice in pitch_gain_search_3tap(). Are there any other places that would benefit from this optimized routine? /* Returns number of shifts to normalize a 32 bit vector to [-16384,+16384). */ 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]));...

...bits. This optimized verison uses the TI NORM instruction rather then max(abs(x)). Other DSPs have corresponding instructions. (BlackFin has SIGNBITS.) */ static int norm_shift(const spx_sig_t *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));...

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,

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