# FaceTime Audio Failure Run Notes

Run directory: `run-20260714T200448Z`

## Timeline

- 2026-07-14 15:04:52 CDT: diagnostics started during FaceTime call.
- 2026-07-14 15:05:38 CDT: user reported call was in failure state; marker `failure` captured. CoreAudio default input was still `Logitech BRIO`.
- Around 2026-07-14 15:05:50 CDT: user switched to AirPods Pro and selected that audio route inside FaceTime to continue the call and be heard by the other caller.
- 2026-07-14 15:05:53 CDT: marker `failure-1505-live-error` captured. CoreAudio default input and output were `James's AirPods Pro`.
- 2026-07-14 15:07:03 CDT: marker `failure-still-error-latest` captured. CoreAudio default input and output remained `James's AirPods Pro`.

## High-Signal Observations

- At the first failure marker, the BRIO route had not disappeared from CoreAudio; it was still the default input at 48 kHz.
- Around the AirPods recovery action, `audioaccessoryd` logged AirPods Pro in `HFP Call` state.
- `avconferenced` logged outbound mic stream health with `averagePower=-120.000000` at 15:05:49 and again at 15:05:54, matching the remote caller not hearing speech.
- FaceTime/AVConference logs in the same window still referenced cached `Logitech BRIO` capture devices after the AirPods route transition.

## Working Interpretation

This reproduces the earlier pattern: the failure is not simply that the default input device vanished. The call's capture/transmit path entered a silent outbound state while BRIO was still enumerated, and manually switching FaceTime to AirPods Pro changed the route enough for the call to continue.