fix(meet-bot): normalize reconnect-reset threshold to audio duration#26509
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
🚩 Pre-existing incorrect frame duration in comments (10ms, not 20ms)
Multiple pre-existing comments claim that 320 bytes at 16kHz s16le mono is a "20ms frame" (lines 12 and 44–46), but the actual duration is 10ms: 320 bytes / 2 bytes-per-sample = 160 samples, and 160 / 16000 Hz = 0.01s = 10ms. A true 20ms frame at 16kHz would be 640 bytes. This doesn't affect runtime behavior (the frame size in bytes is what matters, not the label), but the misleading comments were the source of the old MIN_FRAMES_TO_RESET_BUDGET = 100 being set to half the intended value — the author likely computed 100 frames × "20ms" = 2s, when it was actually 100 × 10ms = 1s. The new PR's formula sidesteps this confusion entirely by computing from first principles, which is a clear improvement.
(Refers to lines 44-47)
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Derive the stability threshold from rateHz/frameBytes so it's consistent across custom audio modes.
Addresses feedback on #26463.