I did test the MR a bit with the game I wrote !9588 for. It's certainly a large improvement but I don't feel like it's rock solid in the "for sure it's not going to be an issue anymore" territory.
I've pushed a new version, which should be much faster. Maybe that's going to solve it?
I'll have a proper look later but I suspect that a 64-tap FIR filter will have a hard time matching the performance of the native 4-tap filter, no matter how optimized it will be. That's not a problem though, see below.
As I mentioned in https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_127395, the FIR we are currently using is very complex. I'm convinced it's too complex, in fact.
I don't think it's too complex, at 44.1 kHz sampling rate 64-tap is the smallest FIR that provides a good stopband attenuation while keeping the transition band above 20 kHz. It's not even considered "high quality" by modern standards.
Right, not especially complex when discussing generic audio resampling filters. For reference, https://src.infinitewave.ca/ has a lot of test results on many audio resamplers used by a plethora of software. Things are quite special for dsound, where you want to resample tens or even hundreds of buffers in real time, often with different and changing sample rates, and use as little CPU time as possible. The current native filter is very likely a sinc filter (see e.g. [https://ccrma.stanford.edu/~jos/pasp/Implementation.html](https://ccrma.stanford.edu/~jos/pasp/Theory_Ideal_Bandlimited_Interpolation.html) for an explanation of the idea). I'll point out that the resampler implementation for a FIR filter and for a sinc one is effectively identical i.e. a convolver. That means that we could swap out the FIR filter with a sinc one at any point and these improvements to the resampler will still be 100% useful even afterwards.
Looking at the dsound impulse response on Win10 (e.g. by running "loopback i" and opening the capture.wav file on Audacity) you can see that 8 output samples are non-0 for each impulse, and they're shaped like the first 2 lobes of a sinc i.e. they're very likely using a 4-tap sinc filter.
Wow, I didn't know that. It explains why there are games that require fast resampling. MS probably changed the resampling algorithm in Vista and the games were released after that without proper testing on XP.
FWIW the dsound.dll installed by winetricks (probably from Win98 times or so) uses linear resampling, so it's likely that games started depending on very fast performance, and accepting the consequent low quality, from the start. At any rate, I am (already was, actually :grinning:) okay with improving the current resampler in this vein, in place of !9588. I'm going to close it and resend the first couple of patches (which are independent anyway) separately. Looking forward to the MRs! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_129027