Speex dev - Feb 2006 - Speex inner_prod()

> That's possible. In any case, u-law conversion can be done with far
less
> than 1 MHz... About Speex, you would likely need to enable ARM
> optimizations and set the complexity to 1 (default it 2).
done with arm optimizations and i was still getting high load ...
guess it's from gstreamer somewhere. I'll check that next week.

thanks,

- Christophe

I am overriding the inner product routine in ltp.c.  To test my replacement,
I threw some test vectors at it.  I understand the loss of resolution caused
by the shift.  I also see a FIXED_POINT danger with the summation of four
mults overflowing the 32 bit before the shift.  

I can fix this by accumulating each term into a long, but if the code scales
the x[],y[] vectors to avoid this problem I could use parallel 16x16
multiply/adds.  

You can see this problem with the following test case.

for (i=0;i<40;i++)
{
	x[i]=-16384;
	y[i]=-32768;
}
sum0=inner_prod(x, y, 40);
fprintf(stderr,"inner_prod0(%8d).\n",sum0);


Jerry J. Trantow
Applied Signal Processing, Inc.
jtrantow@ieee.org

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, on platforms that have a 40-bit
accumulator, it's possible to even remove the shift from the loop and
apply it only at the end.

Le vendredi 03 f?vrier 2006 ? 11:27 -0600, Jerry Trantow a ?crit
:
> I am overriding the inner product routine in ltp.c.  To test my
replacement,
> I threw some test vectors at it.  I understand the loss of resolution
caused
> by the shift.  I also see a FIXED_POINT danger with the summation of four
> mults overflowing the 32 bit before the shift.  
> 
> I can fix this by accumulating each term into a long, but if the code
scales
> the x[],y[] vectors to avoid this problem I could use parallel 16x16
> multiply/adds.  
What do you mean here?
> You can see this problem with the following test case.
> 
> for (i=0;i<40;i++)
> {
> 	x[i]=-16384;
> 	y[i]=-32768;
> }
The value -32768 is not supposed to happen in vectors sent to
inner_prod.
> sum0=inner_prod(x, y, 40);
> fprintf(stderr,"inner_prod0(%8d).\n",sum0);
	Jean-Marc