https://bugs.winehq.org/show_bug.cgi?id=49004
Bug ID: 49004 Summary: Opening Omnisphere VST in FL Studio Host is slow due to ntdll Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: salvieondatrack@gmail.com Distribution: ---
Created attachment 66981 --> https://bugs.winehq.org/attachment.cgi?id=66981 Fl Studio wine output log
First time filing a bug here so bare with me if I miss anything important. OS: Latest stable version of Elementary OS 64bit Wine Version: 5.0 Stable Wine Prefix: 32bitwine
Problem: When I try to run Omnisphere in FL Studio it takes almost a full minute for it to start (only have this issue with Omni). Once it starts, it takes a very long time to load certain patches. My concern is more about the long start time of Omnisphere as the loading of patches can be one of many problems unrelated to this issue.
What I did: I've tested FL studio by running it thru terminal with both overridden and non overridden DLLs. I've also used different Windows versions in the cfg settings. I still receive the same results. I did notice that when I ran omnisphere this message would show in terminal: "0031:err:ntdll:RtlpWaitForCriticalSection section 0x22d9f98 "?" wait timed out in thread 0031, blocked by 0009, retrying (60 sec)". Which explains why it takes a minute for Omnisphere to start. I've attached the terminal log.
FYI I remember reading in a thread somewhere on Reaper that Omnisphere has a problem with permissions involving UAC. I'm not experienced with Wine and only have general Linux knowledge.. Thanks for the help.
https://bugs.winehq.org/show_bug.cgi?id=49004
--- Comment #1 from Salvie salvieondatrack@gmail.com --- In the meantime is there anyway to work around the 60 second time out of trying again? The plugin is usable but it sucks having to wait a full minute because of an abnormality.
https://bugs.winehq.org/show_bug.cgi?id=49004
Salvie salvieondatrack@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64 Distribution|--- |Other
https://bugs.winehq.org/show_bug.cgi?id=49004
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- (In reply to Salvie from comment #0)
"0031:err:ntdll:RtlpWaitForCriticalSection section 0x22d9f98 "?" wait timed out in thread 0031, blocked by 0009, retrying (60 sec)". Which explains why it takes a minute for Omnisphere to start. I've attached the terminal log.
This would be very strange, and not unlikely just a coincidence. The only real effect of the 60-second timeout should be to ensure that message is in fact printed.
https://bugs.winehq.org/show_bug.cgi?id=49004
--- Comment #3 from Salvie salvieondatrack@gmail.com --- (In reply to Zebediah Figura from comment #2)
(In reply to Salvie from comment #0)
"0031:err:ntdll:RtlpWaitForCriticalSection section 0x22d9f98 "?" wait timed out in thread 0031, blocked by 0009, retrying (60 sec)". Which explains why it takes a minute for Omnisphere to start. I've attached the terminal log.
This would be very strange, and not unlikely just a coincidence. The only real effect of the 60-second timeout should be to ensure that message is in fact printed.
OK, so If I understand right it doesn't necessarily mean the process will begin again in a minute but that it could take that much time to start the process?
https://bugs.winehq.org/show_bug.cgi?id=49004
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Salvie from comment #3)
(In reply to Zebediah Figura from comment #2)
(In reply to Salvie from comment #0)
"0031:err:ntdll:RtlpWaitForCriticalSection section 0x22d9f98 "?" wait timed out in thread 0031, blocked by 0009, retrying (60 sec)". Which explains why it takes a minute for Omnisphere to start. I've attached the terminal log.
This would be very strange, and not unlikely just a coincidence. The only real effect of the 60-second timeout should be to ensure that message is in fact printed.
OK, so If I understand right it doesn't necessarily mean the process will begin again in a minute but that it could take that much time to start the process?
It doesn't mean anything clear by itself, it just means that somewhere there is a mutex which a thread has been waiting for for at least 60 seconds.
-
WineHQ Bugzilla