[Speex-dev] Major internal changes, TI DSP build change
jim.crichton at comcast.net
Wed Apr 19 05:03:33 PDT 2006
>> I was wrong, it is the encoder that is not working, and it stopped
>> 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
>> to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build.
>> I am seeing out of the decoder is an extremely low signal (sample values
>> +/-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))
> #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
>> to the data has been trashed. I tried scaling the input data up by a
>> 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
>> look is at line 782, "/*FIXME: This is a kludge that will break
> 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.
More information about the Speex-dev