http://bugs.winehq.org/show_bug.cgi?id=28413
--- Comment #11 from Andrew Eikum aeikum@codeweavers.com 2011-10-28 09:20:54 CDT --- Created attachment 37169 --> http://bugs.winehq.org/attachment.cgi?id=37169 Revert "Revert "winmm: Fix PlaySound so it doesn't block when another sound is already playing."."
(In reply to comment #9)
If you look through git history, you'll notice that I once basically reverted a patch that called waveOutReset from another thread. Witness bug #9026, comment #22. waveOutReset had the obvious benefit to cancel fast, but there were issues caused by calling winmm:waveOutReset simultaneously with winmm:waveOutClose from another thread. I don't think your recent rewrite of parts of winmm has improved things in that area, does it?
I would expect this to work. I wrote it with the intention of being threadsafe. What makes you think it shouldn't?
I think the only practical difference between execution orders is whether waveOutReset() returns buffers or not, since waveOutClose() doesn't return buffers (Should it? I don't see tests for this). It's possible that waveOutReset()'s buffer returning callbacks occur _after_ waveOutClose() has finished, or even after the WOM_CLOSE message, so any WinMM calls within the callbacks would fail. But I think that's fine and matches Windows.
In fact, I went and reverted your revert ("git revert 15ad749eced53e0c33454970bfc2bdb58b64f92b"), resolved a handful of conflicts (patch attached), and the Lemmings behavior was fixed. I grabbed a copy of Spider Solitaire off my WinXP VM and clicked like crazy on a card and wasn't able to cause a crash like Bug 9026 reported.
What do you think about this solution?
(In reply to comment #10)
There's something weird here. The 333ms delay has existed for half a year, see bug #9026, yet the trouble with Lemmix became apparent only with mmdevapi in 1.3.25. IOW, there's something else that changed since mmdevapi, not the 333ms. What piece of puzzle is missing?
Well, the behavior that we're seeing _now_ makes complete sense to me. WinMM doesn't return a buffer until it has completely finished playing, which is why we see the required 333ms delay between PlaySound() calls. I don't know why the old backends didn't have this problem.