http://bugs.winehq.org/show_bug.cgi?id=9026
--- Comment #22 from Jörg Höhle hoehle@users.sourceforge.net 2011-03-27 08:18:17 CDT --- Created an attachment (id=33827) --> (http://bugs.winehq.org/attachment.cgi?id=33827) patch: Let the player thread call waveOutReset itself.
Nobody had noticed this is behaviour introduced with 0.9.39 by commit f44bc89bc41b2b8d75eeb4fc02f5aa587d84c13c
Having the player call waveOutReset instead introduces a maximum delay of 0.333 ms before making room for the next sound. I tested the patch with Chip's Challenge and it sounds ok. I hope it fixes bug #18511 too -- if yes, it's a duplicate.
Conceptually, I'm not fully satisfied with reverting the patch because I think that an app can expect waveOutReset to either return INVALHANDLE when the handle is closed, or return NOERROR. It should not crash because winmm is amid closing. I.e. I'm not convinced the original patch is guilty of assuming thread-safety in winmm.
waveOutReset and waveOutGetPosition are 2 functions likely to be called from another thread.