6dfb1cdf22
After 91eb50ec2f436c026233f184a2dfc7141d6f3b44, we would get random crashes/asserts from the pulseaudio library like: `Assertion 'e->mainloop->n_enabled_defer_events > 0' failed at ../pulseaudio-17.0/src/pulse/mainloop.c:261, function mainloop_defer_enable(). Aborting.` It seems like we would run into a race condition if we didn't guard the pulseaudio flush command with the pulseaudio mutex. This is probably because the pulseaudio thread would try to read the buffer for a tiny bit even after pausing the playback. Sadly the only way to reproduce this is to playback any scene (seem to happen more often if A/V sync is on) and spam play/pause. Note that I could not reproduce this on every computer I tested this on. But by expanding the main pulseaudio mutex lock, I can't seem to reproduce this anymore. So I think that is the correct solution. Pull Request: https://projects.blender.org/blender/blender/pulls/120072 |
||
|---|---|---|
| .. | ||
| PulseAudioDevice.cpp | ||
| PulseAudioDevice.h | ||
| PulseAudioLibrary.cpp | ||
| PulseAudioLibrary.h | ||
| PulseAudioSymbols.h | ||