[Bug 28413] Sound play in games and programs causes brief "pauses"
wine-bugs at winehq.org
wine-bugs at winehq.org
Fri Oct 28 09:20:54 CDT 2011
http://bugs.winehq.org/show_bug.cgi?id=28413
--- Comment #11 from Andrew Eikum <aeikum at 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.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list