Keep meeting system audio alive across repeated sleep/wake and output changes

[claude]

Requested by Justin · project thread

Why

Before: if the Mac slept twice during one meeting, system audio stopped for the rest of the recording. The same happened if the output device changed its sample rate mid-meeting, for example AirPods switching into call mode or a new output device. The mic kept going, so the transcript silently lost the other side of the call. Both are regressions from 1.1.61, because they come from the new Core Audio process tap.

After: system audio comes back after every wake. When the output rate changes, the tap is rebuilt and resampled to the recording's original rate, so the WAV keeps one rate. Stalls still get exactly one reconnect per recording, and a wake, falling asleep or a format change doesn't use it up.

Three causes, all in CoreAudioSystemAudioCapture:

1. Wakes spent the stall budget. Audio kicks recoverAfterSystemWake() on every wake, and that went through recover(), which spends the one-per-recording recoveryUsed budget.
2. Sleep entry spent it too. Hardware test 2026-09-23: the tap stops delivering buffers as the Mac falls asleep, and three seconds later the stall watchdog reconnects. On the second sleep the stall hit the spent budget and failed the tap, then the wake reconnect returned early. Now Audio tells the backend when the Mac is about to sleep, and the tap holds stall recovery until the wake reconnect.
3. Any tap format change was fatal. A code audit (2026-09-23) found the format listener flagged the change, drain called fail("…start a new recording"), and acceptFormat refused any new format even inside recovery. 1.1.61's ScreenCaptureKit path resampled for us.

There was also a status bug that hid the dead tap. "System audio failed - no audio buffers after reconnecting." contains "reconnecting", so it mapped to .reconnecting. A "System audio failed" message now wins.

Hardware: two real sleeps passed on Justin's Mac with causes 1 and 2 fixed. Cause 3 is not yet exercised on hardware.

Product Impact

• Affects: meetings
• Lane: meeting reliability
• Why this matters: closing the lid or switching to AirPods mid-meeting is normal, and it shouldn't cost the other half of the transcript.

What changed

• CoreAudioSystemAudioCapture:
  • recover(_ trigger:) handles .stall, .systemWake and .formatChange. Only a stall spends the one reconnect and shows "reconnecting". A reconnect that starts while another is still waiting for its first buffer releases the earlier one with .recoveryAbandoned, so Audio's write-hold stays balanced.
  • prepareForSystemSleep(): stall recovery waits from will-sleep until the wake reconnect. That hold ends after 30s of awake time.
  • format is the recording's first format, and tapFormat is the live tap's. On a change, acceptFormat builds an AVAudioConverter and convertToRecordingFormat resamples on the consumer queue, never the IO proc. At most 5 format rebuilds per recording (maxFormatReconnects), then it fails cleanly.
• SystemAudioCaptureEngine.prepareForSystemSleep() is a new hook with a no-op default, and the Audio will-sleep observer calls it.
• Audio.updateSystemAudioStatus: "system audio failed" is checked before "reconnecting".
• Tests:
  • Sleep and wake: testEverySystemWakeGetsItsOwnReconnect, testWakeReconnectLeavesStallBudgetForALaterStall, testWakeDuringPendingReconnectKeepsWriteHoldBalanced, testSilenceWhileTheMacFallsAsleepKeepsTheStallReconnect, testSleepThatNeverWakesStopsHoldingStallRecovery, testSleepNoticeAfterStopIsIgnored.
  • Format changes: testFormatInvalidationDiscardsQueuedOldFormatAndReconnectsQuietly, testOutputRateChangeIsResampledToTheRecordingFormat, testAFlappingRouteStillEndsCleanly, testChangedFormatOnWakeIsKeptAtTheRecordingRate. The last two replace the old "format change terminates" and "changed recovery format is rejected" tests.
  • Status: testUpdateSystemAudioStatusTreatsAFailureAfterReconnectingAsFailed.

How I checked it

• scripts/dev/agent-preflight.sh
• python3 scripts/dev/check-build-source-lists.py
• bash build.sh --no-open / bash run-tests.sh / bash run-integration-smoke.sh / swift test: not run locally (no Swift toolchain in this session). CI is the compile.
• Manual check, sleep: two real lid-closes on Justin's Mac, with both sides recorded after each wake.
• Manual check, output change: during a meeting with a video playing, switch the output to AirPods and back. System audio should keep recording, and the log should show no "audio format changed" failure.

Risk Review

• Privacy / local-first behavior reviewed: no data or logging change
• Storage path or migration impact reviewed: none. The system WAV keeps the recording's first rate.
• Public-facing copy stays concrete: no copy change
• Release/update impact reviewed: no version, appcast or cask change
• Agent PRs stay draft until human review
• No private transcripts, audio, tokens, personal paths, or customer data are included

Real-time safety: the IO proc and ring are untouched. Conversion and everything else changed runs on the capture's serial queue, or on main for the status mapping.

Notes

• The mic side of the sleep problem is Don't end a meeting when the mic goes quiet as the Mac falls asleep #1766. Keep AirPods clean after wake, handle Mac sleep quietly, and keep call audio through a rate change #1771 (quiet wake reconnect) is stacked on this PR and Don't end a meeting when the mic goes quiet as the Mac falls asleep #1766.
• Samples already queued under the old format when the rate changes are dropped rather than relabelled. The gap is padded like any other reconnect.

🤖 Generated with Claude Code

https://claude.ai/code/session_015njvTLqC9Fao3TMUNouKka