[Bug 47458] New: Sleeping while pthreads mutex held from the driver code in winepulse-PulseAudio_Support
https://bugs.winehq.org/show_bug.cgi?id=47458 Bug ID: 47458 Summary: Sleeping while pthreads mutex held from the driver code in winepulse-PulseAudio_Support Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bill.huey(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- The SetEvent call in the function pulse_timer_cb() sleeps, calls into the wineserver, while a pthread mutex is held. This can cause long delays in releasing the "pulse_lock" mutex, anywhere from 1-2ms to 90ms that I can see with my custom instrumentation. It potentially can cause dropouts and other issues with audio handling. It seems to be in the main core audio processing loop. The general practice here is to avoid sleeping operations within critical sections. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 --- Comment #1 from Bill Huey (hui) <bill.huey(a)gmail.com> --- This is against master with patches from wine staging, winepulse-PulseAudio_Support -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 Bill Huey (hui) <bill.huey(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bill.huey(a)gmail.com, | |hurikhan77+wine(a)gmail.com Distribution|--- |Ubuntu -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 --- Comment #2 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- So moving this lines if (This->event) SetEvent(This->event); after the pthread_mutex_unlock call would fix the issue you are experiencing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 --- Comment #3 from Bill Huey (hui) <bill.huey(a)gmail.com> --- I don't know the driver that well yet, but it seems like there has to be consideration to AudioClient_SetEventHandle() as well. It looks like that values is set there and it's also held within pulse_lock mutex for safely setting those values. Please, correct me if I'm wrong as I'm new to this code. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 --- Comment #4 from Zebediah Figura <z.figura12(a)gmail.com> --- Do we know for a fact that calling SetEvent() within a mutex does cause dropouts or other poor audio performance? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47458 --- Comment #5 from Bill Huey (hui) <bill.huey(a)gmail.com> --- No, but in my test case for Ableton, it's glitching quite badly. I instrumented the pthreads stuff with pthreads_mutex_trylock as the front end and I'm getting mutex contentions with owners from multimedia DLLs as well as the pulse driver which could be contentions. It's hard to tell what's going on and if this is a normal behavior of the condition variable or not. The case I'm working with is particularly demanding and having this delay in processing is definitely not going to help things -- 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.
participants (1)
-
wine-bugs＠winehq.org