<div dir="ltr">Hi Jean-Marc,<div><br></div><div>Thanks for taking a look.<br><div><br></div><div>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</div><div>to look at the spectrum etc. I've attached a before/after screenshot.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>With interpolated sinc table, a more accurate phase calculation should not have any performance impact. For the full sinc table, it might be possible that more phases need to be calculated (more memory + slower startup).</div><div><br></div><div>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. </div><div><br></div><div>Wim</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 February 2016 at 15:38, Jean-Marc Valin <span dir="ltr"><<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Wim,<br>
<br>
I had a quick look at your patch and I wanted to check what issue you<br>
were trying to solve. Do you have an example where changing the rate<br>
really causes bad artefacts in practice? If so, does that happen on a<br>
single change or only on continuous changes? The reason I ask is that<br>
one of the fundamental design assumptions of this resampler is that rate<br>
changes are relatively infrequent. For continuous rate changes, Erik de<br>
Castro Lopo's Secret Rabbit Code (<a href="http://www.mega-nerd.com/SRC/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/SRC/</a>) becomes<br>
more computationally efficient anyway.<br>
<br>
I'm not against being more careful with the phase, but that would<br>
somehow have to be carefully evaluated since having to reduce the<br>
quality setting to improve infrequent rate changes may not be optimal.<br>
Alternatively, this could be a run-time option similar to the quality<br>
setting.<br>
<br>
Cheers,<br>
<br>
        Jean-Marc<br>
<div><div class="h5"><br>
On 02/04/2016 07:17 AM, Wim Taymans wrote:<br>
> Hi,<br>
><br>
> These patches improve the resampler set_rate function.<br>
><br>
> The first 2 patches do some cleanups in the GCD calculation and avoid an<br>
> overflow when calculating the new phase. This patch could probably be<br>
> simplified<br>
> if we allowed 64bits operations in speexdsp.<br>
><br>
> The 3rd patch avoid rounding errors in the phase calculation. The problem<br>
> is that the new rate is calculated with the reduced rate, which can cause<br>
> large rounding errors and audible artifacts.<br>
><br>
> Patch 4 demonstrates the effect of patch 3. Compare the resampler output<br>
> before and after patch 3.<br>
><br>
> Patch 5 attempts to strike a balance between accuracy and memory usage by<br>
> allowing a small rounding error in the phase.<br>
><br>
> Let me know what you think,<br>
> Wim<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Speex-dev mailing list<br>
> <a href="mailto:Speex-dev@xiph.org">Speex-dev@xiph.org</a><br>
> <a href="http://lists.xiph.org/mailman/listinfo/speex-dev" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/speex-dev</a><br>
><br>
</blockquote></div><br></div>