> 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 > > platform) > > 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.Hi, 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 -- St?phane LESAGE ATEIS International -------------- next part -------------- A non-text attachment was scrubbed... Name: resample.patch Type: application/octet-stream Size: 2433 bytes Desc: resample.patch Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20090613/c5fe948d/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: resample4.patch Type: application/octet-stream Size: 2114 bytes Desc: resample4.patch Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20090613/c5fe948d/attachment-0001.obj
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? Jean-Marc 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 >>> platform) >> 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. > > Hi, > > 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 > http://lists.xiph.org/mailman/listinfo/speex-dev