[Bug 48408] mixthread monopolizes buffer_list_lock if WaitForSingleObject returns quickly, causing livelock and game freeze

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48408

--- Comment #2 from florian.will at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.