Maarten Lankhorst schrieb:
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.
That's great ;)
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.
ok that makes sense. Definitely something wrong in dsound.
But I still think that ALSA_DestroyRingMessage should signal any message left in the queue. Imo it just calls for trouble to expect that messages always are added in the right order.