[Bug 3930] HOMM shows black screen (sound problem)

http://bugs.winehq.org/show_bug.cgi?id=3930

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |t

--- Comment #34 from Jörg Höhle   2010-02-15 11:44:39 ---
Hi,

it would be useful if the many folks interested in this issue could investigate
a little more and figure out the nature of the thread that calls the
CALLBACK_FUNCTION.

A) is one thread created per call to DriverMessage? (ouch, what Damjan's patch
does)
B) is there a unique "WINMM callback thread" that receives one notification per
CALLBACK_FUNCTION event and invokes the function? (i.e. redirecting
DriverCallback FUNCTION to the message queue of one THREAD which then
sequentially calls the functions).
C) is one such thread created per xyzOpen with CALLBACK_FUNCTION?
D) the callback in invoked on the callers thread (some sort of
ExecuteInContext), because winmm processing occurs in another thread already?
E) is that serviced by some other entity altogether?

Then I believe there's a good change to get a patch accepted in Wine.

My observation is that winmm/midi* functions are affected as well as wave*.

MSDN says about MIDI in+out:
http://msdn.microsoft.com/en-us/library/dd798478%28VS.85%29.aspx
 "Applications should not call any multimedia functions from inside the
callback function, as doing so can cause a deadlock..."
People warn against calling winmm functions in various forum posts I googled
up, indeed reporting (sometimes random) hangs on native.
"... Other system functions can safely be called from the callback."
This is different from what Damjan says in comment #18.

I've seen logs of apps calling midiStreamOut from within the MOM_DONE callback
(without hanging). This is clearly not allowed, but apps do so, so Wine must
support it.

There's a particularly interesting note about MEVT_F_CALLBACK:
http://msdn.microsoft.com/en-us/library/dd743561%28VS.85%29.aspx
"Any events after the MEVT_F_CALLBACK event in the buffer will be scheduled and
sent on time regardless of how much time is spent in the callback function."

This suggests that indeed there's a decoupled entity that invokes the callback
functions and does not disturb the time-critical playing of MIDI notes. Wine
currently would freeze MIDI output while busy in the callback.
Perhaps this decoupling only applies to MEVT_F_CALLBACK and not to other
messages like MOM|WOM_OPEN|DONE, but perhaps the mechanism applies to all of
winmm?

Regards,
 Jörg Höhle