Never mind, I ran some tests on Windows and it looks like the DMOs should be applied before resampling, not after.
Very interesting! It would be nice to have some Wine test for it at some point.
Dropped the put\_ changes from this MR. I'll have to move the DMO processing before resampling first ([dsound-dmo-before-resample](https://gitlab.winehq.org/baskanov/wine/-/commits/dsound-dmo-before-resample...)).
I had a cursory look at the branch and I generally like what I see :slight_smile: --- I wrote the following paragraphs before your latest update. The specific point isn't relevant anymore, but I think it can still be useful as a snapshot of what I think about dsound performance at this point. At the moment I think I'd be pretty happy to accept a 20% perf decrease if it avoids having separate code for each src and dst format (be it in separate functions or as switch cases). I rebased my dsound-perf branch on top of current Wine, with the ability to switch between the cubic and the FIR resamplers. It's definitely not clean or nice (e.g. I haven't changed the cubic resampler for the downsample case like you did with the FIR one) but it should be good enough for some rough perf testing and comparison. For reference, running `mixer.exe 128` with the SSE2 cubic resampler uses ~3 times less CPU% for me than with the SSE FIR one (that's on an AMD Ryzen 9 6900HS). I think we're rapidly getting to diminishing returns with further optimizations, outside of "radical" changes like switching the resampling algorithm entirely. Moving the mixing to the `put_` helpers seems like a good idea with not many downsides, in terms of maintainability or otherwise; past that, and generally speaking, I don't think it's worth to significantly increase code complexity for marginal perf gains. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11082#note_144802