Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.

[Anton Baskanov (＠baskanov)]

On Mon Jan 12 13:30:33 2026 +0000, Matteo Bruni wrote:
> I'm curious about your changes. All things being equal it would be
> preferable to improve the existing resampler rather than introducing a
> different one. The problem is that I'm not sure we can make it fast
> enough without effectively rewriting it from scratch.
> When I wrote this MR I felt like the current resampler might be
> hopelessly too complex for realtime resampling of 100+ sound buffers
> (which is what Fallout 3 and New Vegas can end up with on occasion). I
> benchmarked Wine's dsound resampling and compared the performance to
> Windows. I also tested plugging resamplers from other common libraries
> (speexdsp and libsamplerate, before openal-soft) into Wine's dsound, and
> that kinda reinforced my view. The fastest fsinc implementation I tried
> (which is from openal-soft) is still about half as fast as Win 10 /
> 11's, IIRC.
> I can go look at the actual numbers but I'm pretty sure a 5x improvement
> when using explicit SSE does not quite cut it.
> I'll mention that, since I wrote this MR, I have prepared a few more
> patches to improve on other pieces of the dsound mixer, which become the
> bottleneck once the resampler itself gets fast enough. You can find it
> at https://gitlab.winehq.org/Mystral/wine/-/commits/dsound-perf (I
> cleaned the patches up locally since I pushed all that to gitlab, but
> the gist should be there already). For reference, these are the changes:
> - Prepare all the input samples and store all the generated output
> samples in one go instead of doing it sample-by-sample
> - Don't use indirect function calls for sample conversion
> - Don't use indirect function calls for channel interleaving
> - Interleave channels after mixing
> - Mix and apply volume at the same time
> - SSE mixing
> These patches give some incremental performance improvements. It's
> possible that the combination of these and an improved version of the
> current resampler gets us where we want, although I'm not super hopeful...
> Here are my changes: !9928
> When I wrote this MR I felt like the current resampler might be hopelessly too complex for realtime resampling of 100+ sound buffers (which is what Fallout 3 and New Vegas can end up with on occasion).

That's interesting. My changes seem to be enough to fix the crackling in Star Wolves 3, which also creates 100+ buffers. Tested on a laptop with AMD Ryzen 5 3500U with the frequency reduced to 1400 GHz.

I also tried to add AVX+FMA3 versions of the resampling functions, but I'm getting diminishing returns. The bottleneck might be the indirect calls to `get` and `put` or the index calculation code in the outer loop.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_127381