[Speex-dev] Resampler set_rate improvements

[Jean-Marc Valin]

Hi Wim,

On 02/04/2016 10:14 AM, Wim Taymans wrote:
> I've added an example program in the patches that changes the rate
> frequently. You can run test-resample2 >test.raw and open in audacity or so
> to look at the spectrum etc. I've attached a before/after screenshot.

I'll have a closer look at your test program.

> In theory, depending on the current phase and the rate changes that are
> applied, the error can be audible as a pop when changing rates. I've
> tested this with a sine wave, it might not be as significant with
> 'normal' audio.

Just curious, have you tried just doing proper rounding (rather than
truncation as is the case now) to see if it improves?

> The speex resampler is used in pulseaudio to do resampling when matching
> rates between cards etc. In this case, the rate would change quite
> frequently. We would want to enable something more accurate but maybe as
> you say, we should use a resampler more suited for dynamic rate changes...

I can see how that would cause multiple rate changes. At the same time,
since this would be using the interpolated code (unless you're really
lucky with the rate), the cost shouldn't be too high. BTW, do you know
how often the rate gets updated?

> With interpolated sinc table, a more accurate phase calculation should
> not have any performance impact. 

Agreed.

> For the full sinc table, it might be
> possible that more phases need to be calculated (more memory + slower
> startup).

Well, my main concern is that this would make the code switch from the
"direct" resampler to the interpolated one, which is about 4x slower.

> I quite like the speex resampler and its optimizations.  I have not
> tested it but it looks like SRC would need some optimizations before it
> can be used as a replacement, especially compared to the interpolated mode. 

Well, the two designs are very different, with different tradeoffs. In
terms of algorithm alone (not looking at implementation efficiency), the
Speex resampler has less work to do than SRC for each sample it
processes. On the other hand, it has a fixed cost for re-computing sinc
tables every time the rate changes, whereas (AFAIK) SRC incurs no extra
cost if you change rate on every sample. So in terms of frequency of
rate changes, there's a threshold at which the two algorithms are about
the same, but I've never attempted to measure that threshold (it would
depend on optimizations, SIMD, and a bunch of other things anyway).

Cheers,

	Jean-Marc