https://bugs.winehq.org/show_bug.cgi?id=47989
ajduck@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajduck@outlook.com
--- Comment #3 from ajduck@outlook.com --- I can confirm this does happen with FL Studio, but it's strange, it only happens (or doesn't) in certain conditions.
If I run FL directly from the command line with simply "wine FL64.exe", it happens for me, but if I run it from my distro's application menu which (in the .desktop file) has a more complex set of commands for Exec (basic outline: /usr/bin/env sh -c "winepath [...] | xargs -0 'wine FL64.exe'"), it doesn't hang.
It used to hang even with that, and I had to add "&> output.log" somewhere at the end of the Exec command (due to its nesting) in order for it to not hang at start up. Actually that makes it work now when running from the terminal, if I run 'bash -c "wine FL64.exe" &> freezetest.log"'. Try that to see if it runs.
I've also noticed that it can sometimes hang or not hang possibly depending on the distro and what audio driver is being used, e.g. pulseaudio, FL Studio ASIO or wineasio with JACK. I once noticed that when I changed the buffer size for JACK to very high (e.g. 8192 = higher latency) or low (e.g. 16 = lower latency) numbers the hanging either stopped or started. I can't remember exactly what it was doing beforehand however, and this behaviour doesn't happen any more for me.
It almost seems like some sort of race condition to me because of all this weird behaviour.
The RtlpWaitForCriticalSection hang seems to be a wider issue with FL. It's the same thing that's outputted when FL hangs when you try to show the GUI (embedded in an internal FL window) of a plugin "bridged" for compatibility with another bit range (32bit -> 64bit or 64bit -> 32bit). VST hosts can't load up VST plugins with another bit range without this bridging process. That particular issue is detailed in bug #44827.