Joerg-Cyril.Hoehle@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