Persistent audio discontinuity in WASAPI loopback capture when debugging

Question

Persistent audio discontinuity in WASAPI loopback capture when debugging

Yellow Van 25

I am writing a program that captures the output on a Windows device using WASAPI loopback capture. In principle it works correctly, but it breaks whenever I try to debug it, after continuing from a breakpoint.

I can reproduce this in Windows' own example code: I'm using the CaptureSharedEventDriven sample.

Then I followed the instructions to change this demo to use loopback, which is simply:

Change eCapture to eRender in GetDefaultAudioEndpoint
Change eCapture to eRender in EnumAudioEndpoints
Add AUDCLNT_STREAMFLAGS_LOOPBACK to IAudioClient::Initialize call

This now correctly captures the audio output. However, when I breakpoint at the end of CWASAPICapture::Start(...) (line 262 in the sample) and then continue, the capture turns into rubbish from then onwards. The captured audio shows discontinuities every 1056 samples (this is also the buffer size of the IAudioClient) and misses 384 samples every iteration.

I can prove this by adding the following debug code:

[WASAPICapture.cpp, line 358]
hr = _CaptureClient->GetBuffer(&pData, &framesAvailable, &flags, NULL, NULL);
if (SUCCEEDED(hr))
{
   UINT32 framesToCopy = min(framesAvailable, static_cast<UINT32>((_CaptureBufferSize - _CurrentCaptureIndex) / _FrameSize));
   if (framesToCopy != 0)
   {
      //
      // Adding this in order to trace the output issue:
      //
      if (flags & AUDCLNT_BUFFERFLAGS_DATA_DISCONTINUITY) {
         printf("Discontinuity detected, writing %d samples\n", framesAvailable);
      }
      else {
         printf("Correct render, writing %d samples\n", framesAvailable);
      }

After hitting the breakpoint, for the rest of the capture the output will now be:

Discontinuity detected, writing 480 samples
Correct render, writing 480 samples
Discontinuity detected, writing 96 samples
Discontinuity detected, writing 480 samples
Correct render, writing 480 samples
Discontinuity detected, writing 96 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Discontinuity detected, writing 96 samples
etc...

How do I make WASAPI recover from this error?

Xiaopo Yang - MSFT 12,736 Reputation points Microsoft External Staff

2023-03-13T02:59:28.5466667+00:00

Cannot reproduce. Does another sample ApplicationLoopback work for you?

Yellow Van 25

Hi @Xiaopo Yang - MSFT , thanks, this was a very good suggestion. This demo does in fact work, and I think I have found the clue in a comment on the code:

    // A word on why we have a loop here;
    // Suppose it has been 10 milliseconds or so since the last time
    // this routine was invoked, and that we're capturing 48000 samples per second.
    //
    // The audio engine can be reasonably expected to have accumulated about that much
    // audio data - that is, about 480 samples.
    //
    // However, the audio engine is free to accumulate this in various ways:
    // a. as a single packet of 480 samples, OR
    // b. as a packet of 80 samples plus a packet of 400 samples, OR
    // c. as 48 packets of 10 samples each.
    //
    // In particular, there is no guarantee that this routine will be
    // run once for each packet.
    //
    // So every time this routine runs, we need to read ALL the packets
    // that are now available;
    //
    // We do this by calling IAudioCaptureClient::GetNextPacketSize
    // over and over again until it indicates there are no more packets remaining.
    while (SUCCEEDED(m_AudioCaptureClient->GetNextPacketSize(&FramesAvailable)) && FramesAvailable > 0)
  // ... Capture loop

This while-loop is missing in the CaptureSharedEventDriven sample. Based on this comment here, I assume that might in fact be an error??

Further supporting that is that adding the line:

while (SUCCEEDED(m_AudioCaptureClient->GetNextPacketSize(&FramesAvailable)) && FramesAvailable > 0)
  // GetBuffer and ReleaseBuffer

to the CaptureSharedEventDriven sample fixes the reported issue. I would suggest that this is a bug in the aforementioned, and would suggest maybe to update that sample.

With this code added, it recovers correctly from any breakpoint:

* I put a breakpoint here and then continued*
Discontinuity detected, writing 96 samples
Discontinuity detected, writing 480 samples
Discontinuity detected, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
Correct render, writing 480 samples
* It recovered *

Xiaopo Yang - MSFT 12,736 Reputation points Microsoft External Staff

2023-03-17T02:25:16.3+00:00

Hello @Yellow Van , Any update?

Answer accepted by question author

0 additional answers

Your answer

Xiaopo Yang - MSFT 12,736 Reputation points Microsoft External Staff

2023-03-13T02:59:28.5466667+00:00

Cannot reproduce. Does another sample ApplicationLoopback work for you?
Xiaopo Yang - MSFT 12,736 Reputation points Microsoft External Staff

2023-03-17T02:25:16.3+00:00

Hello @Yellow Van , Any update?

Answer 1

Xiaopo Yang - MSFT 12,736 Microsoft External Staff

@Yellow Van You can report the CaptureSharedEventDriven sample's issue at Windows-classic-samples Issues, which may not take into consideration the situation where the audio engine can be reasonably expected to have accumulated about that much audio data. You may also refer to the dedicated loopback sample ApplicationLoopback.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Share via

Persistent audio discontinuity in WASAPI loopback capture when debugging

0 additional answers

Your answer