http://bugs.winehq.org/show_bug.cgi?id=26697
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t Component|-unknown |winmm&mci
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-06 16:43:50 CST --- Please check whether the patch attached to bug #28388 helps. In addition, you may try this hack: diff --git a/dlls/winmm/winmm.c b/dlls/winmm/winmm.c index 9996f11..4260e09 100644 --- a/dlls/winmm/winmm.c +++ b/dlls/winmm/winmm.c @@ -1259,8 +1261,9 @@ the_end: */ static BOOL MMSYSTEM_MidiStream_PostMessage(WINE_MIDIStream* lpMidiStrm, WORD m { if (PostThreadMessageA(lpMidiStrm->dwThreadID, msg, pmt1, pmt2)) { - MsgWaitForMultipleObjects( 1, &lpMidiStrm->hEvent, FALSE, INFINITE, 0 ); + if (GetCurrentThreadId() != lpMidiStrm->dwThreadID) + MsgWaitForMultipleObjects( 1, &lpMidiStrm->hEvent, FALSE, INFINITE, 0 ); } else { ERR("bad PostThreadMessageA\n"); return FALSE;
Your log shows that the app calls midiOutUnprepareHeader and finally midiStreamClose from within a function callback. Wine hangs because it's waiting for an event that is to be delivered by the player thread on which the callback executes. This remembers bug #3930, comment #35.
If Wine's midiStream messaging as seen in MidiStream_PostMessage were changed not to wait for itself and solely queue the message, this app would have a chance to work, even though it performs calls that MS said not to do.
I have started a patch to use SendMessageW instead, then realized that I'm not yet familiar enough with MS-Windows' messaging.
Please report back ASAP, as I could give you yet another patch to try out that would call midiStreamStop and Restart using PostThreadMessage only, without waiting for SetEvent.