https://bugs.winehq.org/show_bug.cgi?id=48408
--- Comment #2 from florian.will@gmail.com --- Thank you very much! This patch indeed fixes those long (eternal?) freezes in the real-world application, Zusi 3.
4f0212c4fd (current git master): Total game freeze when too many secondary buffers are added.
With your patch applied, the game continues when too many secondary buffers are added. (Obviously, sound starts stuttering at that point.)
Compared to my Sleep(1) hack, the sound performance is (of course) better when using your patch, i.e. sound starts stuttering a bit later in the test scenario.
However, using my Sleep(1) hack, I guess the game's main thread is able to remove/add a bunch of secondary sound buffers in quick succession while the mixthread Sleep(1)-s. Using the SRW lock, there is now a freeze for ~5-10 seconds during gameplay when the sound-buffer-heavy game objects (long freight trains) are loaded and unloaded IF the mixthread is unable to keep up with its work. It's probably like this: RemoveBuffer releases lock -> mixthread acquires lock and executes 1 PerformMix iteration (which needs maybe >20 milliseconds) -> RemoveBuffer acquires lock, removes another buffer, releases lock -> mixthread acquires lock again and does another >20ms mix round… and so on. With Sleep(1), this is much smoother, as it probably allows the game thread to remove all those buffers within just 1 millisecond instead of n*20+ milliseconds.
Note that I'm not sure about the explanation in the last paragraph, I just observed the ~5-10 seconds freeze that does not occur with Sleep(1). That freeze occurs at the time when trains go out of "sound range" and sound becomes smooth again (because the number of secondary sound buffers shrinks below ~90).
In "normal" gameplay when the mixthread manages to keep up with mixing and therefore regularly waits for more work, everything seems to work fine with SRWLock.
And in any case, your patch is a HUGE improvement over the old RTL-based mechanism so I'd be happy if it was applied.