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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-resample-Improve-GCD-calculation.patch Type: text/x-patch Size: 1760 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-resample-avoid-overflow-in-phase-calculation.patch Type: text/x-patch Size: 1809 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-resample-avoid-creating-rounding-errors-in-the-phase.patch Type: text/x-patch Size: 862 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-test-add-test-for-dynamic-sample-rate-changes.patch Type: text/x-patch Size: 4488 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-resample-allow-small-errors-in-the-phase.patch Type: text/x-patch Size: 1987 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/a02d0b8b/attachment-0004.bin
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 > Speex-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >
Hi Jean-Marc, Thanks for taking a look. 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. 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. 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... 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). 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. Wim On 4 February 2016 at 15:38, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:> 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 > > Speex-dev at xiph.org > > http://lists.xiph.org/mailman/listinfo/speex-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/43e3c0ee/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2016-02-04 16-06-50.png Type: image/png Size: 535795 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/speex-dev/attachments/20160204/43e3c0ee/attachment-0001.png>