[PATCH 07/25] mciseq: Prevent busy-wait while pausing.

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Thu Oct 4 06:14:29 CDT 2012


Hi,

Now pause won't cause 100% CPU anymore.
That patch supersedes my previous attempt 2 years ago.

Like with mciwave and/or winmm:PlaySound, I managed to keep
all winmm:midi* commands issued from a single thread.
(I've tried hard not to pull at least midiOutOpen into the
 caller thread to easily get its error code).

I've a patch 26 in mind to keep more variables local
to the player rather than in wmm->XY

@@ -773,12 +773,9 @@ static DWORD MIDI_mciStop(WINE_MCIMIDI* wmm, DWORD dwFlags, LPMCI_GENERIC_PARMS
-	    dwRet = midiOutReset((HMIDIOUT)wmm->hMidi);
The player already finishes with midiOutReset.

Another of my design goals was to maintain asynchronous operations as
far as possible.  Most MCI commands should return very soon, because
there are some reports in bugzilla about "app shortly pauses when
executing mci/winmm command XY."  There's even an official MS
Compatibility Hack^H^H^H^HKit to have MCI_CLOSE be fast as it was in w9x.

Well, my PAUSE is fast and doesn't wait for acknowledge from the
player.  STOP without MCI_WAIT is plenty fast too.  OTOH, STOP with
MCI_WAIT and CLOSE both will wait for the player to terminate --
oops, that's patch 9/25.

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-mciseq-Prevent-busy-wait-while-pausing.patch
Type: application/octet-stream
Size: 5877 bytes
Desc: 0007-mciseq-Prevent-busy-wait-while-pausing.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20121004/a6c7b004/attachment-0001.obj>


More information about the wine-patches mailing list