# 2026-07-15 FaceTime Reproduction Notes

## Timeline

- `2026-07-15 11:10:23 CDT`: FaceTime/AVConference logs show the call path selecting `Logitech BRIO` as the audio input.
- `2026-07-15 11:10:35 CDT`: AVConference outbound mic send group reports `averagePower=-120.000000` with low transmit rate (`audioTxBitrate=34kbps`, `primaryAudioTxRate=11kbps`).
- `2026-07-15 11:10:40` through `11:12:05 CDT`: repeated outbound mic send-group silence continues, including several samples with `averagePower=-120.000000` and `primaryAudioTxRate=6-7kbps`.
- `2026-07-15 11:11:01 CDT`: AirPods Pro appear nearby/paired in `audioaccessoryd` logs.
- `2026-07-15 11:12:02 CDT`: AirPods Pro are reported in `HFPCall` / Bluetooth route state.
- `2026-07-15 11:13:18 CDT`: post-workaround marker shows CoreAudio default input and output both set to `James's AirPods Pro` at `24000.0`.
- `2026-07-15 11:13:20` and `11:13:25 CDT`: outbound transmit recovers to about `127-128kbps`, `primaryAudioTxRate=24kbps`, with non-silent average power.

## Evidence

- Focused log window: `failure-1109-window.log`.
- Post-workaround snapshot: `after-airpods-workaround-marker.txt`.
- The 11:06-11:13:30 focused window contains 26 matches for the prior failure signature: outbound send silence and/or low transmit rate.
- No `Input data proc returned inconsistent` CoreAudio converter packet mismatch appears in this focused window.

## Interpretation

This reproduction confirms the same high-level failure class as the July 14 captures: FaceTime/AVConference starts on the BRIO path, then outbound microphone send metrics collapse to silence/low primary transmit rate early in the call. Switching to AirPods Pro changes the CoreAudio route to Bluetooth/HFP and the outbound send metrics recover.

Unlike the July 14 reproduction, this capture does not show the CoreAudio converter packet-count mismatch in the focused window, so that error is not required for the user-visible failure.