Re: Resampler set_rate improvements

Hi Wim,

I had a quick look at your patch and I wanted to check what issue you
were trying to solve. Do you have an example where changing the rate
really causes bad artefacts in practice? If so, does that happen on a
single change or only on continuous changes? The reason I ask is that
one of the fundamental design assumptions of this resampler is that rate
changes are relatively infrequent. For continuous rate changes, Erik de
Castro Lopo's Secret Rabbit Code (http://www.mega-nerd.com/SRC/) becomes
more computationally efficient anyway.

I'm not against being more careful with the phase, but that would
somehow have to be carefully evaluated since having to reduce the
quality setting to improve infrequent rate changes may not be optimal.
Alternatively, this could be a run-time option similar to the quality
setting.

Cheers,

	Jean-Marc

On 02/04/2016 07:17 AM, Wim Taymans wrote:
> Hi,
> 
> These patches improve the resampler set_rate function.
> 
> The first 2 patches do some cleanups in the GCD calculation and avoid an
> overflow when calculating the new phase. This patch could probably be
> simplified
> if we allowed 64bits operations in speexdsp.
> 
> The 3rd patch avoid rounding errors in the phase calculation. The problem
> is that the new rate is calculated with the reduced rate, which can cause
> large rounding errors and audible artifacts.
> 
> Patch 4 demonstrates the effect of patch 3. Compare the resampler output
> before and after patch 3.
> 
> Patch 5 attempts to strike a balance between accuracy and memory usage by
> allowing a small rounding error in the phase.
> 
> Let me know what you think,
> Wim
> 
> 
> 
> _______________________________________________
> Speex-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/speex-dev
>