Peter Beutner schreef:
But this only works if DSOUND_Stop and DSOUND_Release are called from different threads, right?
It is during shutdown, DSOUND has an internal timer/thread called the mixer, it calls DSOUND_Stop because we signalled it to stop playbacking, then the program calls idirectsoundbuffer_release which calls DSOUND_Release. Since DSOUND_release also unsets hwbuf, the timer would then continue to use an uninitialized waveout interface, which could result in something even uglier.
Isn't the real problem that when ALSA_DestroyRingMessage(*) is called from IDsDriverBuffer_Release it doesn't check if there are still any "fast messages" in the queue which wait for their message to be handled? Just from a quick look it seems you could theoretically trigger the same deadlock with the WODM_RESET & WODM_CLOSE messages when using the waveout system.
I agree it's horribly complex, I hope to improve that in alsa during summer. However when calling IDsDriverbuffer_Release dsound says it no longer has anything that uses that interface. Because IDsDriverBuffer_Stop hasn't returned yet this is in fact untrue: it is still using idsdriverbuffer, so to make sure it isn't, dsound has to hold the mixer lock so it waits until the mixer is done playing around.
You are _NOT_ allowed to call Release on a interface if you still have something that uses the interface. The bug is definitely in dsound, it just resulted in winealsa being unresponsive.
Maarten