Capturing call audio on Windows: communications default output, silent loopback, COM apartment error, ConsentStore

Four separate findings from recording meeting and call audio on one Windows 11 PC with a USB headset. The recorder opened the default microphone and a WASAPI loopback of the default output, and chunked both into 30 second pieces for transcription.

1. A headset call plays on the communications default, not the multimedia default

Symptom

Calls taken on the USB headset lost the remote speaker: the loopback recording of "the default output" contained no remote voice, although the person was audible in the headset.

Cause

Windows has separate default render devices per role. The README of the recorder states that Teams and Zoom play through the default communications output, which can differ from the default multimedia output. PortAudio, and PyAudioWPatch (a PortAudio build that exposes WASAPI loopback devices), exposed only the default multimedia output as the default. A loopback opened on that device therefore captured whatever played on the multimedia endpoint, not the call. Before the change the recorder followed only the multimedia default.

Fix used

• Ask Core Audio for the communications endpoint: pycaw's AudioUtilities.GetDeviceEnumerator().GetDefaultAudioEndpoint(EDataFlow.eRender, ERole.eCommunications), then read FriendlyName from the device.
• Find the PyAudioWPatch loopback device whose name contains that friendly name (loopback entries carry a [Loopback] suffix).
• Open it as a second stream when it is not the device the first loopback already uses; treat both as remote-side audio downstream.
• Call comtypes.CoInitialize() in the thread that makes the pycaw call (the recorder ran in its own thread), as noted in the source comment.
• Probe the defaults every 30 seconds and reopen the streams when either default changes.

Caveat

The project notes say that after the recorder restarted both defaults were the headset, so the second stream stayed closed as designed, and that the case where the two defaults differ had not yet been observed in a real call. The explanation is therefore the author's reading of the device roles plus the symptom, not a before/after capture on a machine with different defaults.

2. WASAPI loopback delivers no callbacks while nothing plays

With PyAudioWPatch's callback streams, the loopback stream stops calling the callback when the output is silent. A ring buffer that joins the blocks that arrived and pads only the end with zeros therefore moves speech that follows a silent stretch to the start of the chunk (the review finding recorded in the README).

The first implementation joined the blocks and padded the end. A project memory note summarises the fix as zero-padding by wall-clock time. After a review on 2026-11-12 the code stores each block with its arrival time (a block's arrival time is its end) and places blocks by that time: a gap of more than 0.5 seconds between where the audio so far ends and where the next block belongs is filled with zeros, and smaller differences are treated as callback jitter and joined as they are. The 0.5 second threshold is the author's chosen value.

3. CoInitializeEx fails with RPC_E_CHANGED_MODE

In a separate Python dictation app, a thread that had imported the sounddevice audio library already had COM initialised in a single-threaded apartment. Calling comtypes.CoInitializeEx(COINIT_MULTITHREADED) on that thread raised OSError with winerror == -2147417850 (RPC_E_CHANGED_MODE, 0x80010106). The app catches exactly that code, ignores it, and uses the existing apartment, because the audio device enumerator it calls works from either apartment type. Any other error is re-raised.

The project notes state the cause (an earlier import fixed the apartment) as an observation on that thread; that the enumerator works in both modes is the author's finding for that one call and is not generalised here. The app also sets sys.coinit_flags = 0 before the first comtypes import so that its UI Automation objects share one multithreaded apartment.

4. The microphone ConsentStore stopped listing Teams

The recorder tried to detect "a call is in progress" by reading the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone (and its NonPackaged subkey). Each app subkey records LastUsedTimeStart and LastUsedTimeStop as FILETIME values; a stop of 0 means "in use now". On that PC the entry for the Teams package had a last use of 2026-10-21 when checked on 2026-11-09, so the detector missed Teams calls made since.

Only one machine was observed, and the notes do not say whether a Teams update, a Windows update or a setting caused it. The replacement detector reads window titles of the Teams process:

• <person or meeting> | Microsoft Teams: a call or meeting is up.
• Chat | ..., Calls | ..., Calendar | ...: idle.
• Meeting join | ...: pre-join.
• Meeting compact view | <meeting> | ...: the pop-out window.

These title formats are observed for the new Teams client on that PC and can change with client updates.