Hi,
I've had a hard time finding information about what kind of guarantees MS makes for concurrency in the winmm function set. The best I've found so far is a 2005 blog entry written by Larry Osterman.
Concurrency, part way too many2 - Concurrency and the Win32 API set http://blogs.msdn.com/b/larryosterman/archive/2005/03.aspx "I implicated the concurrency issues when I mentioned that all DLLs need to be multi-thread safe [...]" "The Windows MME APIs (waveOutXxx, waveInXxx, mixerXxx, etc) also protect their internal data structures. But they also support callback functions [...]"
That's short. If you find anything else, please tell me.
The irritating thing about Wine bug #9026 (waveOutReset during waveOutClose) and bug #22978 (MCI_CLOSE) is that they involve no concurrency from the app's POV. In both cases, the app issues a sequence of PlaySound resp. mciSendCommand from a single thread. Concurrency appears as Wine internally makes use of player threads.
Regards, Jörg Höhle