Should Interpolator support f32?

[mitchhentges]

Some other audio-related packages that I'm using for my application both only support up to f32 (C's float) when handling data:

• opus, see opus_encode_float
• rnnoise

Details

On Windows, my pipeline looks like:

1. Get data from WASAPI
   • If device doesn't support F32, convert to f32 here
2. Interpolate sample rate from the device rate to 48_000 as required by opus and rnnoise
   • Upscale from f32 -> f64 as required by sample::Interpolator.
   • Downscale back to f32 once done
   • (I'd like to remove these conversion steps^^^, if possible)
3. Remove noise with rnnoise
4. Encode with opus
5. Send that sucker over the internet

---

This package has been invaluable to me - seeing in easy-to-understand rust an implementation of combining signals, interpolating sample rates and representing how formats look under-the-hood has been awesome! Thanks for your hard work 🎉

[mitchmindtree]

Thanks for the issue @mitchhentges and thanks so much for the kind words!

From memory, the primary reason for using f64 is that the rounding error in f32 is very audible in some occasions (e.g. resampling something like a sine wave), but I agree this should probably be a choice that the user can make. #26 I think is also related to this in a way.

[jmyhrman]

Also chiming in to suggest an f32 option. While on most platforms performance of f32 and f64 math is similar (or even f64 being faster), it is also the case that there exists platforms where f64 math is considerably more expensive (often because of small cache sizes or size of SIMD registers). Therefore it would be preferable to let the user pick f32 vs f64 depending on the particular use-case, even if there are audible artefacts with 32bit precision.

[jmyhrman]

There is also incentive around making it generic over float type such that you can also go for fastfloat type that implements fast-math float operations (as often done in C/C++ for dsp code).