Sample rate conversion going forward

Is your feature request related to a problem? Please describe.

We at this point support a pretty wide variety of sample rate conversion utilities: scipy, libsamplerate, resampy, and soxr. For historical reasons relating to ease of cross-platform packaging, resampy has been the default for quite a while now. However, resampy is also not the best choice for most uses: it doesn’t support stream processing, and it’s not the most efficient implementation for high-quality conversion. (And, as we saw with the recent 0.3 series shenanigans, using parallel compilation for faster resampling can have bizarre interactions with BLAS libraries and cause serious performance degradations.)

I think it’s worth at this point discussing whether it’s worth changing our default resampling parameters and dependency structure. If we do this, I’d like to have it done for the 0.10 series so that it can become a permanent change in the 1.0 release.

Describe the solution you’d like

I’m open to arguments here, but I think the best option is probably soxr. It’s both the most efficient and most accurate in my benchmarks, it has a stream processing interface (for when that becomes important #1518 ), and it has a pretty robust build distribution at this point on both pypi (static-linked wheels) and conda-forge (dynamic link with libsoxr) (thanks @dofuuz!).

We would of course continue to support alternative resamplers as we do now, all that would change is the default parameters (res_type='soxr_hq' for example) and the core requirements would swap out resampy for soxr(-python).

Describe alternatives you’ve considered

We could also use libsamplerate by default. It’s been around longer than soxr-python and might be more stable (from a development perspective), but otherwise I don’t see an argument for it in terms of either efficiency or accuracy.

I see no arguments for using the scipy.signal implementation, other than it would reduce our core dependency stack by one.

Additional context

Some other things to consider in this decision:

1. It will have implications for any function that depends on resampling, eg cqt/vqt, iirt, etc.
2. It will also have implications for any wasm-based distributions in the future. That is, if we want to run librosa in pyodide, we will need to make sure that soxr can also run in that environment. Sticking with resampy by default would sidestep this issue, as resampy depends only on numba, and librosa will need numba anyway.

[dofuuz]

It seems like building python-soxr in ARM mac is OK. I don’t have ARM mac to test on, so I cannot reproduce the problem. It may be Cython bug https://github.com/cython/cython/issues/3820 which is fixed in recent alpha builds. Anyway, I’ll add ARM mac build on next release.

python-soxr supports x86 and ARM platform. On other platform, pip installation may not work in some case. (In this case, user should manually build/install libsoxr and python-soxr.) But anyway, it’s going to be very rare.

[bmcfee]

Spinning off a twitter conversation - there might be an issue with this change and pip installability on certain platforms (mac aarch64, but there could be others). The “easy” solution here is to use conda instead, but that probably will ruffle feathers.

Should we punt on this one until python-soxr has wheels on more platforms? This is a known issue https://github.com/dofuuz/python-soxr/issues/1 / in progress.