unom/punktfunk
8
0
Fork 2
Code Issues 9 Pull Requests Actions 19 Packages Projects 1 Releases 52 Wiki Activity

The macOS device-change recovery answered itself — mic-on streams cut audio and input every ~2.5 s #221

Merged
enricobuehler merged 1 commits from worktree-macos-mic-rebuild-loop into main 2026-08-14 10:49:39 +00:00
Conversation 0 Commits 1 Files Changed 7
+315 -24
1 Commits
Author SHA1 Message Date
enricobuehler e0c10bad85 fix(apple): the macOS device-change recovery answered itself — mic-on streams cut audio and input every ~2.5 s
ci / bun-nix (pull_request) Successful in 22s
Details
ci / docs-site (pull_request) Successful in 1m15s
Details
ci / rust-arm64 (pull_request) Successful in 1m17s
Details
ci / web (pull_request) Successful in 1m25s
Details
apple / swift (pull_request) Successful in 2m6s
Details
apple / distribute (pull_request) Skipped
Details
apple / screenshots (pull_request) Skipped
Details
ci / rust (pull_request) Successful in 4m33s
Details 
The voice-processing engine cannot start on some input devices (field case:
a 6-channel interface — 'combined engine failed to start', every time). The
device-change recovery re-tried it on every rebuild, and the failed attempt's
HAL churn (VPIO builds and tears down an aggregate device) stopped the healthy
fallback engines, which posted the AVAudioEngineConfigurationChange that
scheduled the next rebuild: a self-sustaining ~2.5 s loop for the session's
whole life. Each ~1.9 s rebuild runs on the main thread — where macOS input
capture and sending live — so the stream's INPUT cut out on the same beat,
while video (own socket, own threads) ran untouched; the wire signature
matched network loss and the host's METRONOMIC heuristic pointed at the
display stack, which is what made the field report so misleading.

Three defenses, layered because no single one covers every feedback shape:
a VPIO start failure latches per input device (CombinedTopologyGate — a
rebuild goes straight to the split topology; a different default input earns
exactly one fresh attempt); a configuration change posted by an engine that
is RUNNING is the rebuild's own echo and is ignored (an engine stops itself
before posting, so a live poster was already restarted); and rebuilds that
chain anyway back off exponentially (RebuildBackoff, 0.5 s floor doubling to
a 30 s cap, reset by 10 s of quiet) with a WARN that names the condition.

Both policies extracted to AudioRebuildPolicy.swift where a unit test can
reach them: 7 new tests, the loop test plant-the-defect verified (the shipped
flat floor produces 800 rebuilds in the 10-minute sim; the ladder ≤ 25, and
responsiveness after quiet is asserted). iOS/tvOS semantics untouched.

Gates: swift build + 295 tests 0 failures (macOS), full-package
arm64-apple-ios17.0 typecheck.
 2026-08-14 12:40:51 +02:00