Jan. 28, 2026
12:10 p.m.
On Wed Jan 28 16:57:57 2026 +0000, Matteo Bruni wrote: > > > I realize just now that I should probably clean them up a bit and > make them available... > > > > That would be great. > I pushed them to https://gitlab.winehq.org/Mystral/audio-test-tools. > They're still not especially pretty, but they should get the job done. > > > Actually in one of my followup patches I start storing the buffer > "subsample" cursor position in fixed point, which allows some > simplifications throughout the mixer. > > > > Thanks for the idea. Fixed point might help eliminate the divisions in > the outer loops of `downsample` and `upsample`. Although instead of > 48.16, I'd go for 32.32, as this would make the resampling ratios more > precise and also give a shorter assembly code. And in case of > downsampling, I'd actually invert the fraction so that `freq_adjust_num` > is fixed as we are dividing by `freq_adjust_num` there. > Right, it seems to offer opportunities for simplification elsewhere as > well. Sure, no problems with picking up a different split. > 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. TLDR: I think we > want to simplify the filter as well. > 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. 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. dsoal goes even further and uses cubic > interpolation by default. > FTR, I ended up picking that one in !9588 because I wanted to be sure > that the resampling filter wouldn't be a problem going forward. Sticking > with the current sinc filter is fine but I think we want to tweak the > parameters to bring it roughly in line with the complexity of the native > filter. I'm going to attach a few patches to make_fir showing a few > options. Unsurprisingly, performance improves a lot with shorter filters. - [dsound-fir-order24.txt](/uploads/9956a4793cc611e0cfdcbae5193ccc47/dsound-fir-order24.txt): This one generates an order 24 filter, mostly keeping the general response characteristics of the original filter. - [dsound-fir-order8.txt](/uploads/c9f67299b558532451a51e40fa71aa01/dsound-fir-order8.txt): This is the simplest filter we can get with the current generation approach. Still twice as long as Win10 / Win11, starts breaking WRT aliasing (which I'm pretty sure we can fix somehow, Windows doesn't have this issue). - [dsound-fir-order4.txt](/uploads/b926e76bea683ec74cbd2d1f6cc79858/dsound-fir-order4.txt): This is just a rough draft, most certainly missing pieces, like the resampler changes. The idea is to only store 1 "wing" but still fit the first 2 lobes. I haven't really thought it through, there might be issues with this approach. For reference, with this MR and the order 4 FIR (but otherwise code unchanged) here I get "mixer 128" at maybe 30% CPU usage, while perf shows `DSOUND_MixToPrimary` at 21%, `putieee32` around 8% and both `upsample_sse.L3` and `upsample_sse.L2` close to 6.5%. Once my mixer patches get rid of the top two symbols in this perf output here, this should go safely into "fast enough" territory. Bottom line: I'm okay with optimizing the current resampler along the lines of this MR (again, great job, I thought it was unsalvageable :sweat_smile:). Afterwards I'll want to simplify the actual filter as well, ideally to be competitive against modern Windows in performance and quality. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_128292