http://bugs.winehq.org/show_bug.cgi?id=28413 --- Comment #12 from Jörg Höhle <hoehle(a)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.