http://bugs.winehq.org/show_bug.cgi?id=9220
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #13 from Jörg Höhle hoehle@users.sourceforge.net 2010-01-20 17:25:18 --- I hacked winmm.c:midiOutOpen and midiStreamOpen to open uDeviceID=0 (the first device) when given -1/FFFF (MIDI MAPPER). This allows ff7demo to not hang in winmm and proceed to show the intro logos. After those, the knight enters the scene. It crashes a little later, when the knight swings his sword.
This worked with both timidity and fluidsynth as ALSA sequencers. With timidity, music is awfully chopped.
This seems to show that the MIDI mapper produces errors or return codes that the app does not expect. (Likewise, the wave mapper is not return-code compatible with native, and I believe some apps get confused, but I don't know the details).
Perhaps there's also a "callback on different thread" issue mentioned in bug #3930 ? In http://msdn.microsoft.com/en-us/library/dd757372(VS.85).aspx MSDN says "Playback ... continues ... regardless of how much time is spent in the callback function." Are they sent from another thread (or interrupt)? Wine calls FUNCTION callbacks synchronously in driver.c:DriverCallback AFAICT. A long lasting callback (or thread suspension) would stop playback in Wine.
Tested in Ubuntu with AC'97 Intel onboard sound, wine-1.1.36.
Interestingly, I also got past the winmm hang with neither timidity nor fluidsynth running. The menu mentioned "MIDI-through port". Retesting this, it even went past the "swing the sword" crash. Nevertheless, ff7 crashed a little later, still in the intro, when the knight faces 3 monsters, not always at the same spot.