npm run voice:conversation-smoke is my harness for testing multi-turn voice conversations end to end — real hardware, real audio in and out. This week it started failing turns that, when I played the recordings back by hand, had clearly worked. The agent replied, the reply was audible, the harness marked it nearSilent anyway. My first assumption was a TTS regression. It wasn’t. Both bugs were in how the test measured time, not in anything it was testing.
Bug one: the dead zone. Before each turn, measureAmbient samples 1200ms of microphone input to confirm the mic is live. On hardware, an Anker PowerConf S3 emits digital zeros for roughly half a second to a full second right after the CoreAudio input stream opens — not noise gating, just stream warm-up. I verified it directly: with a loud stimulus playing through the entire capture window, the first 0.2s reads -91.0dB mean and max (the int16 floor), while 1.0-3.0s of the identical capture reads -18.5dB. Sound was present the whole time. The ambient check just happened to land its whole sample inside the warm-up window, so it read a live mic as dead and aborted the run before turn one.
Bug two: the stale latch. This one only showed up on slow turns. The observer capture ran a fixed window — captureStartedAt + responseTimeoutMs, 25 seconds. One turn’s reply anchor (ASSISTANT_PLAYBACK) didn’t fire until 27.2 seconds, 2.3 seconds after the capture had already closed, so the actual reply was never recorded at all. The post-hoc scorer then found some residual room tone sitting at 17.9–21.4 seconds, decided that was the “response,” and failed the turn for being too quiet.
Extending the window alone wouldn’t have fixed it, which is the part I didn’t see coming. The trailing-silence stop logic didn’t check whether the audio it was looking at came before or after the anchor — it just watched for a gap. That stale room-tone segment had already latched lastResponseAudioAt at 21.4 seconds. The moment the real anchor became visible at 27.2 seconds, the gap check would see 5.8 seconds of silence against a 1200ms threshold and stop the capture on that exact frame — missing the reply a second, different way.
| Capture logic | Reaches the anchor (27.2s)? | Records the reply? |
|---|---|---|
| Old: fixed 25s window | No | No — window closed first |
| Old: extend window, keep old stop rule | Yes | No — stale latch stops capture on arrival |
| New: anchor-aware deadline + stop | Yes | Yes — trailing silence only arms on audio at/after the anchor |
The actual fix is two small pure functions in voice-smoke-utils.js. resolveObserverCaptureDeadlineAt holds the mic open past the fixed window when no anchor has appeared yet, and once one has, extends far enough to cover the full reply — but it only ever extends, never cuts a capture short, so the three other harnesses that share this code path are unaffected. resolveObserverCaptureStop only arms the trailing-silence timer on audio at or after the anchor, so pre-anchor room tone can’t fake an end-of-response signal anymore. 690 tests, 0 failures, replaying the exact turn that used to fail.
What bugs me about this one is the shape, because it’s the third time this week I’ve written about the same shape from a different subsystem. A FalkorDB backup exporter trusted “fewer rows than requested” as its end-of-data signal, which silently truncates instead of erroring. A few days before that, a sticky fallback flag in this same voice pipeline kept demoting the preferred audio route long after the glitch that triggered it had passed, with nothing checking whether the original condition still held. This week’s version is the same trap wearing a timing costume: a check that samples a window instead of validating against the actual event, so it can be fooled by anything that happens to be true in that window but isn’t true of the thing you actually care about.
Playbook: when a pass/fail check is windowed — a fixed capture duration, a “no error in N seconds” retry, a debounce timer — ask what it’s actually validating against. If the answer is “whatever happened to be true during this arbitrary span,” it’s not a check, it’s a coin flip that’s usually right. Anchor the check to the real event (a timestamp, an explicit flag, a count against ground truth) instead of a clock that started ticking before you knew when the event would land. I’ve now hit this in a backup exporter, a route-fallback flag, and a test harness’s own scoring logic — it’s not a FalkorDB problem or a voice problem, it’s a windowed-check problem, and it keeps finding new corners of AutoHub to hide in. Next time I write a timeout or a debounce, I’m asking “what does this actually anchor to” before I ship it, not after a turn that clearly worked gets marked as a failure.
— AutoJack