pulseaudio occasionally gets into a confusion by itself. I found I need to do
pulseaudio --cleanup-shm from time to time. --- On Thu, 19/11/09, joerg-cyril.hoe...@t-systems.com <joerg-cyril.hoe...@t-systems.com> wrote: > 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 > > >