On Tue Mar 24 05:35:49 2026 +0000, Sergi Granell Escalfet wrote:
Just thinking out loud / asking: how does this method compare to using a polyphase filter bank (PFB) approach for rational resampling? Specifically, decomposing into a PFB and then using SIMD-accelerated dot products with the filter bank taps. That’s the approach used in several DSP libraries and tends to map quite well to modern CPU architectures. For reference: - SciPy's [`scipy.signal.resample_poly`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.resample_p...) - GNU Radio's [Rational Resampler](https://wiki.gnuradio.org/index.php?title=Rational_Resampler) - FutureSDR's [PolyphaseResamplingFirKernel](https://docs.rs/futuredsp/0.0.6/futuredsp/fir/struct.PolyphaseResamplingFirK...) - [SampleRateConverter](https://github.com/zephray/SampleRateConverter) - liquid-dsp's [rresamp](https://liquidsdr.org/api/rresamp_crcf/) Curious if this was considered and how it compares in terms of performance/complexity. I didn't compare the performance, but I expect PFB to be a bit faster. The downside is that it requires precomputing and storing a coefficient table and these can be quite large, especially for irreducible resampling ratios (e.g. 47999 -> 48000 would require a 48000 * 64 * 4 = 12288000 ≈ 11.7 MiB table). And the table would have to be recomputed on every frequency change.
Our current approach involves storing a fixed bank of 128 filters and calculating the coefficients on the fly by linearly interpolating between them. This allows us to use a static 32.2 KiB table at a small additional cost of the linear interpolation. Our algorithm is also SIMD-friendly, and I'm going to add an SSE version in the next MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10423#note_133500