https://bugs.winehq.org/show_bug.cgi?id=54246
--- Comment #5 from amberjulee@yogirt.com --- Ok I got it, the 089E8108 critical section is managed by application code.
As I understand it: internal FAudio thread A calls FAudio's DecodeBuffers, which calls user callbacks (OnBufferBegin/End) while holding bufferLock. User callbacks try to lock user mutex M. At the same time user thread B calls SubmitSourceBuffer while holding the same user mutex M. SubmitSourceBuffer needs to access bufferLock to add a new buffer into the queue and tries to lock it, but it's already acquired by thread A. Deadlock.
Basically what we need is for DecodeBuffers to not hold bufferLock (or any other mutexes I guess?) while calling app callbacks because there's a possibility that the app has some nasty global mutex.