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