# FaceTime Audio Dropout Findings

## Confirmed Failure

- James reported the remote caller could no longer hear him at `2026-07-14 14:11:34 CDT` (`2026-07-14T19:11:34Z`).
- At the confirmed failure snapshot, CoreAudio still reported the default input as `Logitech BRIO`, UID `AppleUSBAudioEngine:Unknown Manufacturer:Logitech BRIO:0259AEF1:4`, nominal sample rate `48000.0`.
- The periodic route sampler showed `Logitech BRIO` remained the default input at `14:09:17`, `14:09:48`, `14:10:18`, `14:10:48`, and `14:11:18 CDT`.
- By `14:11:48 CDT`, the default input/output had switched to `James's AirPods Pro` at `24000.0`, matching the manual workaround route change.

## Second Reproduction

- James reported the call was in the error state at `2026-07-14 15:05 CDT` during a later FaceTime call.
- At `15:05:38 CDT`, the first failure marker still showed CoreAudio default input as `Logitech BRIO` at `48000.0`.
- Around `15:05:50 CDT`, James manually switched to AirPods Pro and selected that route inside FaceTime to continue the call and be heard by the other caller.
- At `15:05:53 CDT` and `15:07:03 CDT`, CoreAudio default input/output were `James's AirPods Pro` at `24000.0`.
- During the route change window, `audioaccessoryd` logged AirPods Pro in `HFP Call` state, while `avconferenced` still logged outbound mic send-group silence with `averagePower=-120.000000` at `15:05:49` and `15:05:54`.
- The same log window still showed FaceTime/AVConference references to cached `Logitech BRIO` capture devices after the AirPods route transition.

## Third Reproduction

- James reported the problem recurred near the beginning of a FaceTime call on `2026-07-15`, roughly around `11:09 CDT`, and he had to switch to AirPods Pro.
- The focused unified-log window from `11:06:00` to `11:13:30 CDT` shows the active call path starting at about `11:10:23 CDT`, with FaceTime/AVConference selecting `Logitech BRIO` as the input device.
- By `11:10:35 CDT`, AVConference outbound mic send metrics show `averagePower=-120.000000`, `audioTxBitrate=34kbps`, and `primaryAudioTxRate=11kbps`.
- From `11:11:40` through `11:12:05 CDT`, outbound mic send metrics repeatedly show `averagePower=-120.000000` with `primaryAudioTxRate=6-7kbps`.
- At `11:12:02 CDT`, `audioaccessoryd` reports AirPods Pro in `HFPCall` / Bluetooth route state.
- At `11:13:18 CDT`, the post-workaround marker shows CoreAudio default input and output both set to `James's AirPods Pro` at `24000.0`.
- By `11:13:20` and `11:13:25 CDT`, outbound transmit has recovered to about `127-128kbps`, `primaryAudioTxRate=24kbps`, with non-silent send average power.
- This reproduction does not show the `Input data proc returned inconsistent` CoreAudio converter packet-count error in the focused window, so that error is not required for the user-visible failure.

## Strongest Evidence

- Before the reported failure, FaceTime's AVConference process repeatedly logged outbound microphone send-group silence:
  - `14:10:28`: `averagePower=-120.000000`, `audioTxBitrate=38kbps`, `primaryAudioTxRate=5kbps`.
  - `14:10:33`: `averagePower=-111.549454`, `audioTxBitrate=37kbps`, `primaryAudioTxRate=5kbps`.
  - `14:10:38`: `averagePower=-120.000000`, `audioTxBitrate=38kbps`, `primaryAudioTxRate=5kbps`.
  - `14:10:43`: `averagePower=-120.000000`, `audioTxBitrate=39kbps`, `primaryAudioTxRate=6kbps`.
  - `14:10:48`: `averagePower=-120.000000`, `audioTxBitrate=37kbps`, `primaryAudioTxRate=5kbps`.
- Around and after the reported failure, `avconferenced` emitted repeated CoreAudio converter errors:
  - `Input data proc returned inconsistent 480 packets for 3840 bytes; at 4 bytes per packet, that is actually 960 packets`.
- `audioaccessoryd` repeatedly logged `inputDeviceChange, Wx addr found NULL` and nearby route updates during the call, even while the CoreAudio default input remained the BRIO.
- At `14:11:43 CDT`, `audioaccessoryd` reported `James's AirPods Pro` in `HFP Call`, then the audio route changed to Bluetooth.

## Interpretation

The failure is not simply the macOS default input disappearing or switching away from the BRIO. The default input remained `Logitech BRIO` through the failure window.

The failure appears inside FaceTime/AVConference's capture/transmit path for the BRIO input: it continues to think the BRIO is the input device, but the local mic stream periodically collapses to digital silence and low primary transmit rate. The repeated packet-count mismatch from CoreAudio's converter points to a stream format/buffer sizing issue in the FaceTime/AVConference audio pipeline, likely involving the USB BRIO audio device.

AirPods/nearby-device smart routing is also active during the call and may be contributing route churn, but the primary symptom is the AVConference mic stream going silent while the BRIO remains enumerated.

## Captured Artifacts

- `confirmed-failure-marker.txt`: exact user-reported failure timestamp plus route snapshot.
- `confirmed-failure-window.log`: five-minute unified log slice around the confirmed failure.
- `live-audio-focused.log`: focused live stream collected during failure.
- `audio-state-samples.log`: periodic CoreAudio default route samples.
- `audio_state.swift`: local CoreAudio route/device inspector.
- `skill-runs/run-20260714T200448Z/run-notes.md`: second reproduction timeline and user-observed AirPods recovery step.
- `skill-runs/run-20260715T161259Z/run-notes.md`: third reproduction timeline, post-AirPods marker, and focused 11:09-ish log window.