[Speex-dev] Major internal changes, TI DSP build change

[Jim Crichton]

>> I was wrong, it is the encoder that is not working, and it stopped 
>> working
>> in build 11103.  The log message for this build is "another 640 bytes
>> removed from the encoder state (using the input data instead of copying 
>> it
>> to st->frame/st->inBuf)".  Only nb_celp.c/h are changed in this build. 
>> What
>> I am seeing out of the decoder is an extremely low signal (sample values 
>> of
>> +/-10, in this build, by build 11126 the output is almost all zeros).
>
> That's quite strange, but I think I figured it out. Could you try
> changing the definition of SHL32 in fixed_generic.h from
> #define SHR32(a,shift) ((a) >> (shift))
> to
> #define SHR32(a,shift) (((spx_word32_t)(a)) >> (shift))
>
> This is not the correct fix, but if it does solve the problem, then I
> know how to fix it properly (by using EXTEND32) in svn.
>
>> It may be a compiler hiccup in scaling/shifting, or else somehow the 
>> pointer
>> to the data has been trashed.  I tried scaling the input data up by a 
>> factor
>> of 10, and this affected the output, but it is still just low amplitude
>> noise.  I will look some more tomorrow.  Maye the first place that I 
>> should
>> look is at line 782, "/*FIXME: This is a kludge that will break 
>> eventually
>> */.
>
> Yeah, that code sort of makes too many assumptions, but they happen to
> be valid for now. I suspect the shift (described above) to scrap the top
> 16 bits when I attempt to shift a 16-bit value.

You found it.  The SHL32 (not SHR32) line fixes the problem.  It must be 
doing a 16-bit shift, then extending the result (which is reasonable).  As 
it happens, that it the same macro which gave us trouble last May 
(25th/26th), when the C55 build was more subtlely broken.

I will test the C54 build and send a patch tomorrow with updates to the .pjt 
files (adding window.c) and bits.c, as I described earlier.

- Jim