dsound: Make sure we're holding the lock on Drop And Stop , try 2

Peter Beutner p.beutner at gmx.net
Sat Apr 21 10:11:44 CDT 2007

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.

More information about the wine-devel mailing list