[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