Dead air before the system speaks needs filler
Aliases: thinking earcon · floor-holding feedback · wait cue
What it is
“Weather in Kyoto Thursday through Sunday” has been said. ASR, NLU, and the weather service still need nearly two seconds. The room is silent. What the user hears is not “the machine is computing.” It is “it missed me / it died / I should shout it again.” Pre-response filler is the signal that occupies the floor after the system has taken it and before the first contentful syllable: an earcon, a brief “one second,” a visual that listening ended and compute began. It addresses system-side latency, not a user who has not finished speaking.
Why it happens
In conversation, a gap on the order of a second after a question starts to sound like trouble: a dispreferred answer, a mishearing, or a floor that fell on the ground. People fill that gap with backchannel and floor-holders (“mm,” “let me see”). A dialogue system that stays mute while it computes produces an unmarked pause: the user cannot tell “I have the turn” from “your talk was lost.” The blank is interpreted against turn-taking norms, not against a latency SLA.
Filler’s job is to announce: the floor is mine, I am working. It can be a non-speech earcon or a very short utterance. Without it, people repeat the whole command into the delay — which is taken as new input, shoves aside the in-flight computation, and makes the delay worse. Stretch the filler into a full “sure, I’ll look up four-day weather in Kyoto,” and it becomes a new, barge-able turn: latency converted from compute into something to listen to.
Studying it
Factor delay by filler. Set time from endpoint to first audio packet at 300 / 800 / 1500 / 2500 ms, with and without an earcon or a particle. Dependent measures: full-command repeats during the delay, “are you there,” and extra wakes launched because the user thought nothing landed. Do not stop at satisfaction: people can call the response “natural” and still have re-asked at 1.5 s.
The control must not be “play a fake answer before content is ready.” Filler has to be floor-holding, not a proposition that could be heard as the result. On devices with a screen, add a visual-spinner arm and test whether auditory filler is still needed when the eyes are on the device.
Where it stops holding
When the first packet already lands around 300 ms, extra filler is noise, especially on short commands. Filler that sounds like a real reply (“okay, yes”) is heard as confirmation and people start barging. The same thinking sound looping too many times turns from holding the floor into nagging. In public, any extra speech has social cost; a light or a haptic may beat “one second.” IVR hold music is a different filler family, scaled in minutes; it does not design a two-second assistant gap.
Applying it
- If expected time from endpoint to first content exceeds about 0.7 s, emit a floor-holder immediately after endpoint. Do not wait for the model’s first token.
- Use different sounds for “heard you” and “still working.” The first sits at endpoint; the second only while compute has not finished.
- Allow barge-in during filler. Barge-in should cancel this computation, not parse the filler as user speech that needs understanding.
- Plot delay against repeat-during-delay. If the repeat curve still climbs after filler is added, the floor-holder is too late, or it does not sound like holding the floor.