Hi,
Testhq.org results from 17th of November about winmm:mci were striking:
All machines producing a timeout had "f11" in their name.
(Another day, some f11 machines passed the tests).
http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_Wine.html
Please test whether the following patch correlates with hanging machines.
Not checking waveoutwrite's return code for sure has the potential to hang the
play loop, waiting for a buffer to come back that was never sent out in case of
error.
But then, why did waveOutWrite fail? That's what I'd like you to investigate.
Why Fedora 11?
Below patch only adds error reporting to the mciplay loop. Feel free to add the
same to the mcirecord loop.
diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c
index cdf9146..fdb6b18 100644
--- a/dlls/mciwave/mciwave.c
+++ b/dlls/mciwave/mciwave.c
@@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR
dwFlags, DWORD_PTR pmt,
&waveHdr[whidx], waveHdr[whidx].dwBufferLength,
waveHdr[whidx].dwBytesRecorded);
dwRet = waveOutWrite(wmw->hWave, &waveHdr[whidx], sizeof(WAVEHDR));
+ if (dwRet) ERR("Write %d\n", dwRet);
left -= count;
wmw->dwPosition += count;
TRACE("after WODM_WRITE dwPosition=%u\n", wmw->dwPosition);
@@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR
dwFlags, DWORD_PTR pmt,
WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */
/* just to get rid of some race conditions between play, stop and pause */
- waveOutReset(wmw->hWave);
+ dwRet = waveOutReset(wmw->hWave);
+ if (dwRet) ERR("Reset %d\n", dwRet);
waveOutUnprepareHeader(wmw->hWave, &waveHdr[0], sizeof(WAVEHDR));
waveOutUnprepareHeader(wmw->hWave, &waveHdr[1], sizeof(WAVEHDR));
A future patch will abort the loop in case of error. However so far, when
creating
situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR
message
was never triggered.
So the cause of random mci time-out on test.winehq may as well lay elsewhere.
Thanks for your help,
Jörg Höhle
