https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #46 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Alexander E. Patrakov from comment #45)
No, this will not allow resampling multiple streams simultaneously, as all the resampling is currently done in the (single) mixer thread. Moving resampling outside of the lock will still be beneficial, because it will allow other threads (that presumably produce sound) to do useful work while the mixer thread is resampling.
My plan was to get it outside the lock first and, if that's good enough, then stop there. If that's not good enough then my thought was to have the mixer thread manage a dynamic pool of re-sampler threads. This would be worse than what we do now on a single core system, so I'd obviously like to avoid that if I can.
And please don't move resampling to some other thread that already exists -- the problem is that there is no reliable event to trigger it. E.g. some games simply don't unlock their secondary buffers. Also, it is very hard to handle the situation where a game writes some audio data to its secondary buffer speculatively and then corrects it later, because the output also depends on some data immediately preceding what was overwritten.
I would imagine that if I attempted to do that then it would get shot down on wine-devel pretty quickly.