winmm: GetCurrentPadding is superfluous while recording. (try 2)

[Joerg-Cyril.Hoehle at t-systems.com]

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.

Because the 3 mmdevapi drivers don't yet correctly implement the
IAudioCaptureClient_Get/ReleaseBuffer protocol, I've added a normally
superfluous ReleaseBuffer(0).

With that in place, the "Fix AudioCaptureClient protocol" patches can be applied on
the winmm side. DSound capture looks ok. ALSA is already submitted, Andrew will
hopefully submit the OSS equivalent soon, and I'll likely add the CoreAudio one this
week-end, after looking into that 0/4096 frames issue.

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).

Regards,
 Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-winmm-GetCurrentPadding-is-superfluous-while-record.patch
Type: application/octet-stream
Size: 2681 bytes
Desc: 0001-winmm-GetCurrentPadding-is-superfluous-while-record.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20120111/20ac7dec/attachment.obj>