CoreAudio WASAPI Loopback on Windows 11 ARM: IAudioCaptureClient::GetNextPacketSize always returns 0

武林 汪 0 Reputation points
2026-01-06T08:06:22.35+00:00

Environment:

  • OS: Windows 11 ARM64 (version xxxx)
  • Device: Snapdragon / ARM-based PC
  • Audio API: WASAPI (Shared Mode, Loopback)
  • Compiler: MSVC / VS2019 / VS2022
  • Architecture: ARM64 native (not x64 emulation)

Issue:

IAudioCaptureClient::GetNextPacketSize() always returns 0,

even though audio is playing through speakers.

Initialize flags:

AUDCLNT_STREAMFLAGS_LOOPBACK |

AUDCLNT_STREAMFLAGS_RATEADJUST |

AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM

Observations:

  • Same code works correctly on x64 Windows 10/11
  • IAudioClient::Start() succeeds
  • No AUDCLNT_E_* error returned
  • GetBuffer() is never called because packet size is always 0

Question:

Is this a known limitation or bug on Windows 11 ARM?

Is loopback capture officially supported on ARM64?

Are there additional requirements or flags on ARM?

Windows development | Windows API - Win32
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Jack Dang (WICLOUD CORPORATION) 7,815 Reputation points Microsoft External Staff Moderator
    2026-01-06T09:55:47.9433333+00:00

    Hi @武林 汪 ,

    Thanks for reaching out.

    Based on what you’ve described, this behavior does not appear to be caused by an obvious issue in your application code, and it aligns with differences that have been observed between x64 and ARM64 environments when using WASAPI loopback capture.

    Here’s how your questions can be addressed with the information currently available:

    Is this a known limitation or bug on Windows 11 ARM?

    There is no publicly documented Microsoft statement confirming this as a known limitation or bug. However, the symptoms you’re seeing - IAudioCaptureClient::GetNextPacketSize() consistently returning 0 without errors while audio playback is active - have been reported by multiple developers when testing WASAPI loopback on Windows ARM64 devices.

    Since the same code works as expected on x64 systems, this points toward a difference or gap in the ARM64 audio stack implementation rather than an application-level issue, although it has not been formally classified by Microsoft.

    Is loopback capture officially supported on ARM64?

    WASAPI loopback capture is documented as a Windows feature in general (see “Loopback Recording” in the Windows Core Audio documentation), but the official documentation does not explicitly state support guarantees or behavioral parity for ARM64: https://learn.microsoft.com/windows/win32/coreaudio/loopback-recording

    The APIs are present and callable on ARM64, but there is no clear statement confirming that loopback capture is fully supported or expected to behave identically to x64. As a result, reliability on ARM64 cannot currently be assumed based solely on the existing documentation.

    Are there additional requirements or flags on ARM?

    At this time, there are no documented ARM-specific flags or additional requirements for enabling WASAPI loopback capture. The flags you’re using (AUDCLNT_STREAMFLAGS_LOOPBACK, AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM, AUDCLNT_STREAMFLAGS_RATEADJUST) align with the official WASAPI guidance provided in the Core Audio documentation.

    There is no publicly documented alternative configuration for ARM64 if loopback capture fails to produce audio packets.

    Practical guidance

    • Your implementation and flag usage are consistent with the documented WASAPI loopback approach.
    • The behavior difference appears tied to the platform rather than compiler, architecture mode, or initialization errors.
    • If reliable loopback capture is a strict requirement, testing and validation on x64 Windows remains advisable.
    • On ARM devices, some applications rely on alternative capture paths (such as vendor-specific drivers or higher-level capture mechanisms), though these are outside the scope of standard WASAPI loopback.

    Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.