Voice for DeepSeek Harness: the interruption problem, and how I ended up measuring the echo instead of guessing a threshold
Heat trend
Collecting trend data
The percentage is based on available heat signal, not comment count or independent people.
A developer using voice to code with DeepSeek Harness faced an interruption problem: the agent's spoken replies would be picked up by the open microphone, causing a feedback loop. To solve this, instead of guessing a fixed audio threshold, the system measures the echo during the first 500 ms of each reply. This echo serves as the baseline, and only audio that exceeds this baseline by 3x and holds for 320 ms is registered as speech, allowing for dynamic adaptation to environmental changes like headphones or door slams.
The problem. I write most of my code by voice. Any hands-free setup has the same failure: while the agent reads its reply aloud, the microphone has to stay open if you want to interrupt — but then the turn detector hears the reply coming out of the speaker, decides it was spoken to, and the thing talks to itself in a loop.
What already existed, and why it didn't fit me. There are good voice plugins for the harness — dsh-voice-mode, dsh-ears, dsh-talk. I studied all three. Two things I couldn't get from them: they're built English-first (reasonable, wrong for me — the browser recogniser mangles Spanish), and all of them solve the echo problem by simply refusing to listen while speaking. Which works, and means you can't interrupt.
What I did. Two parts.
The mic now closes when the first word is actually spoken, not when the message is sent. It was closing at send time, so during a multi-second think there was no echo to defend against and the thing was deaf for no reason.
And for interrupting during playback: I don't guess a threshold. A fixed number is a bet about someone else's room and speakers — too low and it cuts itself off constantly, too high and it never triggers. Instead, the first 500 ms of every reply the mic just listens, and what it hears is the echo, by definition, because nobody has spoken yet. That's the floor. To count as speech, audio has to clear it by 3× and hold for 320 ms. Re-measured per reply, so headphones going on mid-session adapt automatically, and a door slam is too short to trigger it.
Two things that would have made it useless: stopping the current utterance isn't stopping (the read loop starts the next chunk half a second later), and the detector's buffer already contains the echo — so unless you flush it, what you send to Whisper starts with the plugin's own voice.
Eleven tests over the decision logic, including the two that matter: the echo must not trigger it, and neither must a bang.
MIT, dsh-kitt-voice on npm. Source: https://github.com/kittcat-lab/dsh-kitt-voice
Happy to be told the approach is wrong — I've only tested it on my own hardware.