[Speex-dev] Resampler saturation
jean-marc.valin at usherbrooke.ca
Sun Jun 14 11:44:26 PDT 2009
Just to make sure I understand, the two patches you sent are two
different ways to fix the problem, with the only difference being that
resample.patch converts the "unrolled by four" loop into a plain one
that's easier on DSPs, right?
Stephane Lesage a écrit :
>> Quoting Stephane Lesage <stephane.lesage at ateis-international.com>:
>>> Is this a bug ? Is it possible to fix it ?
>>> (I use version speex 1.2beta2, because newer versions just
>> don't work
>>> on my
>> This is probable the cause. 1.2beta2 was the first release to
>> include the resampler and it had many bugs. I suggest trying
>> to get 1.2rc1 (or latest git) working.
> I found the problem preventing to use version >= 1.2beta3.
> After the patch for SSE, resampler_basic_direct_single() has been modified to use float instead of the generic spx_word16_t type...
> Anyway, float implementation is perfect, because handling saturation when converting back to int.
> After reconverting to spx_word16_t, the fixed point version is now good, except for saturation.
> Using MULT16_16 for convolution, we have 1 guard bit, which seems to be enough in resampler_basic_direct_single(), so we can saturate before storing.
> But in resampler_basic_interpolate_single(), we can also saturate in the cubic interpolation part.
> So I propose shifting the 32 bits accumulators 1 bit right before this operation.
> --> Implemented and tested in resample4.patch
> About the 4 accumulators:
> Simple DSPs have only 2 accumulators, so this is really not good on DSPs for 2 reasons:
> - this inserts extra load/store operations, cutting performance in half
> - we lose the accumulator register guard bits
> However, for resampler_basic_interpolate_single(), this is actually better to keep only 1 loop, because of caching for the input samples.
> --> See resample.patch
> Speex-dev mailing list
> Speex-dev at xiph.org
More information about the Speex-dev