Feature request: smooth fade-out when the agent is interrupted

[miguelmoralai]

Feature request: smooth fade-out when the agent is interrupted

The problem

When a user starts talking over the agent and the SDK confirms an interruption, the agent's voice stops instantly. The decision to stop is correct — but the abrupt cut, often mid-word, is the single most "robotic" artifact we hear on real phone calls.

Here's an example of what it sounds like today — the user interrupts and the agent stops abruptly:
https://drive.google.com/file/d/128KuaXsuUTkGBBxy9ycaxNI__Q4Pap-9/view?usp=sharing

We're on livekit-agents 1.6.0.

What we'd like

A supported option to let the agent's voice fade out over a short window (~100–250ms) when an interruption is confirmed, instead of cutting instantly.

To be clear about scope: this is only about the way the agent stops, not when. Interruption detection would stay exactly as it is — same rules, same timing. The only thing that changes is that the last fraction of a second fades out smoothly instead of being chopped off.

Ideally this would be a simple, declarative setting — something like:

interruption_fade_out = 0.2   # seconds; 0 = instant cut (today's behavior)

[dorukdumlu]

I'd like to take a shot at this — I built hybrid barge-in handling for a production telephony agent and the hard cut on interruption was one of the most audible quality issues we had.

Looking at the code, the abrupt stop comes from clear_buffer() in _ParticipantAudioOutput plus AudioSource.clear_queue(): frames already pushed into the rtc.AudioSource queue (up to queue_size_ms=200) can't be modified anymore, so there's nothing left to fade at that point.

The approach I'd propose: an opt-in fade stage in the AudioOutput chain (fits the existing next_in_chain design). It holds back a small tail buffer (~100ms) before forwarding frames downstream; on clear_buffer() it applies a short linear gain ramp (say 50–80ms, configurable) to the held frames, pushes them, then clears. Cost is added playback latency equal to the tail buffer, which is why it should be opt-in — something like fade_out_on_interruption: float | None = None on the session/output options.

Two questions before I write it: (1) chain node vs. building it directly into _ParticipantAudioOutput — any preference? (2) is added latency of ~100ms acceptable as an opt-in tradeoff, or would you rather see a smaller default tail?