barge-in lets a caller interrupt a voice agent's spoken reply. the system stops the audio and gives the caller room to speak. someone who hears the wrong date or wants a shorter answer can say so without waiting through the rest of the reply.
how does barge-in work?
the microphone stays active while the tts audio plays. voice activity detection flags possible speech then interruption logic decides whether the caller is trying to take the turn.
a cough should not stop a sentence. neither should every "mm-hmm." the system can use speech duration, recognized words or an interruption model to judge whether to keep speaking or stop.
when it accepts an interruption, the application stops playback and clears the queued audio. it can also cancel unfinished generation if the pipeline supports it. cancelling tts alone is not enough because audio already sent to the player can keep playing.
the conversation history should record how much of the reply the caller heard. otherwise, the next answer may refer to an instruction that never played. livekit tracks playback progress and interrupted transcripts, including partial speech when playback stops.
barge-in example
a caller misses the appointment time while a clinic voice agent is speaking.
voice agent: "your appointment is on thursday at three thirty. please bring your previous prescription and..."
caller: "sorry, what time did you say?"
the agent stops listing what to bring and lets the caller finish. it answers, "three thirty on thursday," before continuing with the appointment instructions.
barge-in vs endpointing
barge-in stops an agent's reply when the caller interrupts. endpointing decides when the caller has finished and the agent can answer.
difference | barge-in | endpointing |
|---|---|---|
trigger | the caller speaks during the agent's reply | the caller pauses or stops speaking |
decision | should the current reply stop? | has the caller finished their turn? |
action | stop playback and clear queued audio | close the caller's turn and prepare a reply |
common failure | ignores a correction or stops for background noise | cuts off a hesitation or adds a long wait |
after stopping for an interruption, the agent still needs endpointing. hearing "sorry" is enough to consider yielding but the rest of "what time did you say?" tells it what to answer.
why does barge-in matter for voice agents?
when a voice agent reads the wrong date, the caller should be able to correct it before it moves on to the next instruction. barge-in stops the reply so the agent can hear that correction. without it, the caller has to wait or talk over the audio.
rumik's livekit integration uses rumik.TTS() for speech generation and livekit for interruption handling.
a brief "okay" usually lets the conversation continue. "wait, that's the wrong date" asks for a change. an agent that stops for both will break up its own explanations while one that ignores both will miss corrections. good interruption handling leaves acknowledgments alone and gives the caller room to finish a correction.
