How to test barge-in in a realtime avatar app

Test barge-in by speaking while the avatar is already answering, then checking three separate outcomes: whether its audible reply stops, whether its visible behavior remains coherent, and whether its next answer uses your correction. A successful connection is not evidence that interruption handling works. Use the same prompts, microphone conditions, and recording method for every candidate API, and treat the results as observations from your test rather than universal latency guarantees.

Separate interruption from the end of a turn

A pause inside a sentence and an interruption during the agent's reply are different events. In the first case, the system must decide whether the user has finished. In the second, it must decide whether new speech should displace output already playing. Combining both into a single responsiveness score hides useful information: an agent can respond promptly after silence but still continue talking over a correction.

LiveKit's official turn-handling documentation distinguishes turn detection, endpointing, voice activity detection, and interruption handling. It describes several detection modes and separate options for false interruptions. Those distinctions make a useful evaluation checklist even when you are buying a managed avatar API rather than configuring a voice pipeline yourself. They do not establish that every avatar vendor exposes the same options, uses the same implementation, or produces equivalent results.

• LiveKit: turn detection and interruptions

Start with one small, repeatable conversation

Use a fictional ordering exercise rather than an open-ended debate. Ask the avatar to help place a coffee order, restrict it to a few short questions, and tell it to use the customer's latest explicit choice. Keep the menu and any prices fictional. This creates an easily observable correction without requiring the reviewer to judge subjective qualities such as charm or emotional intelligence.

For Realtime Avatar, the documented Next.js integration separates a server-side route from the browser call component. The server holds the API credential, authorizes requests, and supplies session policy; the browser connects through the proxy. Follow that documented integration instead of inventing a client-side interruption endpoint. The downloadable starter provides a practical starting point, but its local-development authorization must be replaced before hosting it for other users.

• Next.js integration guide and starter
• Session policy and call lifecycle

Keep the setup unchanged while comparing runs. Record the browser version, input and output devices, whether the user wears headphones, the network conditions, and the chosen avatar. A microphone capturing sound from speakers presents a different situation from a headset. Neither result should silently stand in for the other. Do not change multiple settings between attempts and then attribute an improvement to one of them.

Run four scenarios, not one impressive demo

1. Baseline: ask for a coffee and let the avatar finish. Check that the response is relevant before testing interruptions.
2. Correction: while the avatar is responding, say, 'Actually, make that tea.' Check whether the next relevant response uses tea rather than coffee.
3. Continuation: pause partway through your own request, then complete it. Record whether the avatar begins before you intended to finish.
4. Backchannel: use a brief acknowledgment such as 'mm-hm' while the avatar speaks. Record whether it continues or stops, then assess whether that observed behavior suits your application. This test does not assume the provider offers a setting to change it.

These are proposed acceptance scenarios, not claims about a particular vendor's measured accuracy. Choose the expected behavior for your application before running them. A training exercise may intentionally let the character finish an instruction, while a conversational assistant may need to yield immediately to a correction. A test is only useful when the reviewer knows which behavior the product is supposed to deliver.

Repeat the correction at different points in the reply: near its beginning, in the middle, and close to its end. Preserve failures instead of retaining only the best recording. Report how many attempts you ran and how many satisfied each criterion. If you test multiple people or languages, keep those groups visible rather than folding them into a single number that conceals the weakest case.

Measure what the user hears, then what the system understands

For a manually reviewed recording, mark the onset of the user's correction and the last audible portion of the displaced avatar reply. Their difference is a useful interruption-stop interval for that recording. Mark the start of the next relevant answer separately. Do not call either interval startup latency, and do not equate a connection-ready event with the first audible response. They describe different parts of the experience.

A screen recording alone may not capture microphone input and remote audio accurately. Verify the recording path with a short baseline before collecting a comparison. When possible, keep distinguishable input and output tracks, and describe their timing limitations. If your method cannot reliably resolve a short delay, report that limitation instead of presenting a precise millisecond figure. No performance result is claimed in this article.

Stopping quickly is not sufficient if the next answer ignores the correction. Score semantic recovery independently: did the avatar replace the earlier choice, ask a relevant clarification, or continue with stale information? Also inspect the video for extended speaking motion after audio has stopped, unexpected freezes, or an abrupt restart. These observations help distinguish an audio-control issue from a dialogue-state or presentation issue without guessing at a provider's internal implementation.

• Separate startup and spoken-turn measurements

Keep the result useful for a shipping decision

Store one row per attempt with the scenario, setup, observed behavior, outcome, and a recording reference. Keep the raw observations alongside any aggregate. Agree on acceptable failure rates and timing goals for your use case before comparing providers; a target you choose is not a benchmark the provider has achieved. Where sample sizes are small, say so plainly and use the result to guide further testing rather than a sweeping ranking.

Finally, test the surrounding controls: ending a call, recovering from denied microphone permission, and starting a fresh session after a failed attempt. Keep test sessions bounded and avoid collecting real customer details in the fictional exercise. Before release, repeat the same scenarios on the actual devices and network conditions your users will have. The goal is not to prove that an avatar can be interrupted once; it is to know what your application does when a real conversation changes direction.