search for: norm_shift

...really use tmp=NEG32(tmp+1), since the range of negative fixed point has one more number for a given number of bits. (and that's what all the shifting is about) This same code fragment is in normalize16() and compute_rms() and a couple of other spots. I think it should be encapsulated into a norm_shift() function that can be overridden for specific processors. Similarly, the AEC code uses FLOAT_ADD, _SUB, _MULT routines in pseudofloat.h could be improved by shifting negative mantissa's >= -16384. if (r.m>0) { if (r.m<16384) { r.m<<=1; r.e-=...

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

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,

...es are scaled to 16384, I can add the results of the two _dotp2()s together before the long add without worrying about overflow. I didn't understand that inner_prod() was always passed scaled vectors. That's the danger of optimizing routines without knowing how they are called. I split a norm_shift() out of your normalize16(). This function can 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_...