[Bug 28413] Sound play in games and programs causes brief "pauses"

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Oct 28 10:15:12 CDT 2011


http://bugs.winehq.org/show_bug.cgi?id=28413

--- Comment #12 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-10-28 10:15:12 CDT ---
>waveOutClose() doesn't return buffers (Should it?)
No, there's WAVERR_STILLPLAYING.

>so any WinMM calls within the callbacks would fail
It's not external calls that fail, it's winmm internally which got corrupt, as
one call had already progressed past the "fetch object if handle ok" check in
winmm then got preempted, then another thread closed the device.
=> crash when the first thread resumes.

I'll have to carefully review the current winmm code, but I can't remember
seeing protections like InterlockedIncrement around winmm calls which I see as
a means to verify that no other thread is currently using a given handle, so I
have some doubts it's safe now.  Is there any other means?
IIRC, CreateTimer uses this technique to tell whether a timer callback is still
executing.

>clicked like crazy
You want to configure windows/win.ini, see bug #21277 comment #3 to use
PlaySound via my MCI shell:
sound default
sound systemasterisk notify
sound systemexclamation notify
[copy&paste a dozen of these lines from an editor to a wine console]

>we see the required 333ms delay between PlaySound() calls
Perhaps previously, when queued fast, the player was aborted even before
submitting the first header.  If that's not the case anymore, one needs to
understand where the change in behaviour comes from.

-- 
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