Speex dev - Apr 2006 - Major internal changes, TI DSP build change

> 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.

	Jean-Marc

>> 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

> 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.
Yes, that's what I finally remembered. I think I've fixed all
occurrences (by adding EXTEND32) in svn. Could you check if that's the
case? 
> 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.
Good, thanks.

	Jean-Marc