One thing I’d be careful about here is the timing of the final decode. Say the Bluetooth input is running at 16 kHz mono, and the route switches to the built-in mic at 44.1 kHz while the decoder still has unprocessed frames from the previous utterance. If the VAD and endpointer reset immediately, how do you make sure those buffered frames are actually decoded before the old state is discarded?

I’d probably treat the route change as a boundary between two audio segments: stop accepting frames from the old capture session, drain its pending audio through the existing resampling and decode path, emit a final result if there’s enough speech to recover, and only then reset the endpointing state for the new input. Otherwise, even if the ring buffer survives the switch, the sentence can still disappear because the decoder never gets a chance to finish it.

There’s another edge case worth thinking about: what happens if a route change lands while the capture callback is still delivering buffers in the old format? For example, a Bluetooth headset disappears, the input switches to the built-in mic, and a delayed callback from the old tap arrives after the new resampler has been configured.

If both streams write into the same ring buffer, I’d want some explicit guarantee that frames from different input configurations can’t be interpreted using the wrong sample rate or channel layout. One approach would be to tag buffers with a capture-generation ID and format metadata, then reject stale callbacks while keeping the old segment available for final decoding. That would also make rapid headset connect/disconnect cycles easier to handle without accidentally mixing audio across route changes. Does the current capture layer already guard against that race, or is that something you’re planning to address alongside utterance preservation?

Fixed in 0.1.3, now on pub.dev. Testing it showed two problems, not one. On iOS, re-activating the audio session during the change was refused, so the mic could stop entirely; a route change now rebuilds only the engine. And the sentence in progress is now finished instead of dropped.

The order you describe is how it works now. The ring only ever holds 16 kHz mono, because each tap callback converts before it writes. So on a route change the audio already buffered from the old route is drained into the endpointer first, the open sentence is emitted as a final result and queued for the decoder, and only then is the endpointer reset for the new input. The decoder runs separately, so the reset can't cancel a decode that's already queued.

On stale callbacks: the old tap is removed and the engine stopped before the new converter is built, so a buffer in the old format shouldn't reach it. There's no explicit check, though, and checking each buffer's format against the converter's input is cheap, so I'll add one.