What happens upon mmdevapi capture overrun on native?

Hi,

Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9:
> - Reworked capture logic to always capture, since that seems to be the case on windows,
>
> when stopped we simply drop whole packets, but keep firing the event.

Does anybody know what precisely happens upon overrun during capture?

A. mmdevapi fills the whole buffer once.  It keeps firing events and
   sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer.
   This is like mciwave's "record from 0 to 5000" command.
   The client can read the oldest recorded samples.

B. mmdevapi continuously overwrites the circular buffer.  It keeps
   firing events and sets the DISCONTINUITY flag too.  The client gets
   to see the newest recorded samples.  It's like your TV recorder's time
   shift function that can only travel back by as much as the buffer holds.

C. Other, e.g. mixing newest with older packets (current winealsa).

In other words, what data does the dlls/mmdevapi/capture test see in:
http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc6...

I think A makes sense but really I don't know.  The tests show a
position jump by one period worth of frames when reading the next
packet after an overrun.  That's not what I'd expect from behaviour A.
But from behaviour B I'd expect a much larger position jump, as large
as elapsed time.

We really need somebody with a microphone and Vista/w2k8/w7 to tell us what happens.

Does anybody know what DSound does in such a case? (not that it matters...)

Thank you,
      Jörg Höhle

[Maarten Lankhorst]

Hey Joerg,

Op 09-03-12 17:46, [e-mail] schreef:
> Hi,
>
> Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9:
> > - Reworked capture logic to always capture, since that seems to be the case on windows,
> >
> > when stopped we simply drop whole packets, but keep firing the event.
>
> Does anybody know what precisely happens upon overrun during capture?
>
> A. mmdevapi fills the whole buffer once.  It keeps firing events and
>    sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer.
>    This is like mciwave's "record from 0 to 5000" command.
>    The client can read the oldest recorded samples.
>
> B. mmdevapi continuously overwrites the circular buffer.  It keeps
>    firing events and sets the DISCONTINUITY flag too.  The client gets
>    to see the newest recorded samples.  It's like your TV recorder's time
>    shift function that can only travel back by as much as the buffer holds.
>
> C. Other, e.g. mixing newest with older packets (current winealsa).
>
> In other words, what data does the dlls/mmdevapi/capture test see in:
> http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc6...
>
> I think A makes sense but really I don't know.  The tests show a
> position jump by one period worth of frames when reading the next
> packet after an overrun.  That's not what I'd expect from behaviour A.
> But from behaviour B I'd expect a much larger position jump, as large
> as elapsed time.

I suspect B, the position jump makes sense in that case, because
if you compare it with rendering on underrun clock doesn't get
increased, so it makes sense on capture clock doesn't increase
as well, and the discontinuity simply signals that an underrun has
occurred that's at least a period long. The exact clock time
passed will not matter. mmdevapi doesn't measure that in
shared mode.

It's also the only way the discontinuity flag would make sense
and for the tests to pass, otherwise you would have set it on
the first newly captured buffer after you finished reading out
all old data.

~Maarten

Hi,
> > A. mmdevapi fills the whole buffer once.
> > B. mmdevapi continuously overwrites the circular buffer.
> > I think A makes sense but really I don't know.
>
> I suspect B

I realized that I don't need a microphone if I can trust
IAC_CaptureClient's pu64QPCPosition output parameter: "the value of
the performance counter at the time that the audio endpoint device
recorded the device position of the first audio frame in the data
packet."

Modifying the capture tests to trace that value shows that mmdevapi
mostly implements behaviour A with a few quirks.  Please visit bug
#30147 for details.

Regards,
    Jörg Höhle

[Maarten Lankhorst]

Hey Joerg,

Op 12-03-12 11:01, [e-mail] schreef:
> Hi,
> > > A. mmdevapi fills the whole buffer once.
> > > B. mmdevapi continuously overwrites the circular buffer.
> > > I think A makes sense but really I don't know.
> >
> > I suspect B
>
> I realized that I don't need a microphone if I can trust
> IAC_CaptureClient's pu64QPCPosition output parameter: "the value of
> the performance counter at the time that the audio endpoint device
> recorded the device position of the first audio frame in the data
> packet."
>
> Modifying the capture tests to trace that value shows that mmdevapi
> mostly implements behaviour A with a few quirks.  Please visit bug
> #30147 for details.

Thanks for figuring it out. winepulse v10 carries the fixed behavior,
diff with v9 attached below for completeness.

commit 9173c8dd53438eeb395ff7ac66498bdbb383474f
Author: Maarten Lankhorst 
Date:   Tue Mar 13 11:04:04 2012 +0100

winepulse: v10

diff --git a/dlls/winepulse.drv/mmdevdrv.c b/dlls/winepulse.drv/mmdevdrv.c
index af8a826..50dcd4a 100644
--- a/dlls/winepulse.drv/mmdevdrv.c
+++ b/dlls/winepulse.drv/mmdevdrv.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright 2011-2012 Maarten Lankhorst
  * Copyright 2010-2011 Maarten Lankhorst for CodeWeavers
  * Copyright 2011 Andrew Eikum for CodeWeavers
  *
@@ -574,9 +575,11 @@ static void pulse_rd_loop(ACImpl *This, size_t bytes)
         UINT32 src_len, copy, rem = This->capture_period;
         if (!(p = (ACPacket*)list_head(&This->packet_free_head))) {
             p = (ACPacket*)list_head(&This->packet_filled_head);
-
-            next = (ACPacket*)p->entry.next;
-            next->discont = 1;
+            if (!p->discont) {
+                next = (ACPacket*)p->entry.next;
+                next->discont = 1;
+            } else
+                p = (ACPacket*)list_tail(&This->packet_filled_head);
             assert(This->pad == This->bufsize_bytes);
         } else {
             assert(This->pad < This->bufsize_bytes);