joerg-cyril.hoe...@t-systems.com writes: > Hi, > > now winmm recording does not depend on chunking by mmdevapi. > > + if(packet > 0) > + WARN("losing %u frames\n", packet); > That part is interesting. Another approach would have been to check whether > all of GetData could be stuffed into winmm buffers and use ReleaseBuffer(0) > if not > (much more complicated in the presence of several buffers). > > As long as winmm supplies enough buffers in advance, that doesn't matter. > > With that in place, the "Fix AudioCaptureClient protocol" patches can be > applied on > the winmm side. I have not checked the dsound code. > > I'm sorry winmm:ACMPullData was broken by my former notification patch. I'll > have to fix that. > ACMPullData is also not very robust (return; after GetBuffer will prevent any > subsequent GetBuffer > with OUT_OF_ORDER).
It doesn't work here: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok [...] err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 etc. forever -- Alexandre Julliard julli...@winehq.org