Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows + CPAL + SHOW_SAVE_PANEL = lockup #1021

Open
jneem opened this issue Jun 5, 2020 · 3 comments
Open

Windows + CPAL + SHOW_SAVE_PANEL = lockup #1021

jneem opened this issue Jun 5, 2020 · 3 comments
Labels
bug does not behave the way it is supposed to shell/win concerns the Windows backend

Comments

@jneem
Copy link
Collaborator

jneem commented Jun 5, 2020

On windows, if I initialize an audio device using cpal then any subsequent attempts to SHOW_SAVE_PANEL lock up my program. I have a branch in which I've modified the open_save example to demonstrate this behavior.

This was observed on the Windows 10 evaluation version available here, running in virtualbox.

@luleyleo luleyleo added bug does not behave the way it is supposed to shell/win concerns the Windows backend labels Jun 5, 2020
@jneem
Copy link
Collaborator Author

jneem commented Aug 28, 2020

Upon further investigation, this also happens when using gstreamer to play audio (however, with gstreamer it isn't triggered just by initializing gstreamer; I need to actually create an audio pipeline).

I've done a little more investigation (with cpal because it's simpler). The druid main thread blocks on IModalWindow::Show, which eventually results in a call to NtWaitForMultipleObjects. There are tons of threads blocked on NtWaitForWorkViaWorkerFactory, and then one thread blocked on GetMessageExA (which eventually also leads to NtWaitForMultipleObjects) and another thread blocked on NtUserCallHwndParamLockSafe that has things like DialogBoxIndirectParamW in its call stack.

I'm pretty clueless at this point, but maybe tomorrow I'll try to see if #1068 is relevant.

@jneem
Copy link
Collaborator Author

jneem commented Sep 9, 2020

I managed to fix the lockup by doing all audio-related stuff on a separate thread. In gstreamer, it seems that I need to create the audio pipeline on a different thread; in cpal, I need to initialize the audio device on a separate thread. Maybe this is just something you have to do on windows? I couldn't find anything about it anywhere 🤷

@Zarenor
Copy link
Collaborator

Zarenor commented Sep 9, 2020

This definitely sounds a little odd to me, but if the audio lib is expecting to own the event pump for the thread (and go into an event-handling mode), that could cause this, because Druid runs on OS event loops - we don't roll our own and then pull from a separate message queue. That is, when our event-update-layout-paint cycle ends, we yield back to the OS, which is free to call back in with an event at it's leisure (or to choose not to).

I'm not familiar enough with how the audio side of things works here to know if there could be some fix we could make easily in Druid for this to behave better... The thing that definitely seems strange to me is the modal window causing a freeze. Can you close the modal, or does it freeze so that you can't?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug does not behave the way it is supposed to shell/win concerns the Windows backend
Projects
None yet
Development

No branches or pull requests

3 participants