Live API (gemini-3.1-flash-live-preview): VAD silently drops short user utterances right after a model turn (telephony, audio provably delivered)

[MichelN89]

Note: we use the Live API over the raw BidiGenerateContent WebSocket (not this SDK), but filing here as Live API model-behaviour reports appear to be triaged in this repo (cf. #1894). Happy to move this wherever it belongs.

Summary

models/gemini-3.1-flash-live-preview (Live API, audio-to-audio, telephony use case) consistently ignores short user utterances (~1–2s) spoken shortly after the model finishes its own turn. No inputTranscription is produced for them, no turn is opened, no error is returned — the session just stays silent until the user produces a longer utterance. Callers experience this as "the agent suddenly went away" and hang up.

Evidence (production call, 2026-08-24, ~08:01–08:02 UTC)

Timeline reconstructed from our bridge logs + the dual-channel call recording:

t (rel)	Channel	Event
60.8s	model	Model finishes turn (asks "shall I continue?"), turnComplete received
61–62s	caller	"Ja, dat hoort." — clear speech (verified, see below) → no VAD trigger, no transcription, no response
68–69s	caller	"Ben je er nog?" — clear speech → ignored again
74–79s	caller	Longer complaint sentence (~5s) → turn finally triggers, model responds normally

Three independent verifications:

1. Audio was delivered continuously. Our bridge streams 20ms PCM16/16k chunks (converted from 8kHz μ-law telephony audio) via realtimeInput.audio; send counters show an uninterrupted ~50 chunks/sec throughout the window, no WS errors, no reconnects, no goAway.
2. The speech is objectively clear. The same inbound audio (from the call recording, same leg) fed to gemini-3.7-flash generateContent transcribes perfectly, including timestamps: [0:01-0:03] (clear speech): "Ja, dat hoort." / [0:09-0:10] (clear speech): "Ben je er nog?". So Gemini's own STT understands this audio — only the Live VAD gate in front of it drops it.
3. VAD was configured at maximum sensitivity at the time of the call:

"realtimeInputConfig": {
  "automaticActivityDetection": {
    "startOfSpeechSensitivity": "START_SENSITIVITY_HIGH",
    "endOfSpeechSensitivity": "END_SENSITIVITY_HIGH",
    "prefixPaddingMs": 300,
    "silenceDurationMs": 800
  }
}

The same pattern occurred on earlier calls (e.g. 2026-08-22: a short "Ja." confirming a question was ignored for 25s until the caller spoke a longer sentence) — also with default VAD settings, so it is not caused by this particular tuning.

Setup

• Model: models/gemini-3.1-flash-live-preview, raw WebSocket v1beta.GenerativeService.BidiGenerateContent
• Audio in: PCM16 @16kHz (upsampled from 8kHz μ-law telephony), 20ms chunks, sent continuously (no client-side gating)
• responseModalities: ["AUDIO"], speechConfig.languageCode: "nl-NL", input/output transcription enabled (languageCodes: ["nl-NL"]), sessionResumption + contextWindowCompression.slidingWindow enabled, ~15 function declarations + googleSearch
• System instruction ~9k chars

Expected

A clear 1–2s utterance after the model's turn should open a user turn (or at minimum produce an inputTranscription), especially with START_SENSITIVITY_HIGH.

Actual

Short utterances right after a model turn are silently dropped; longer utterances work. This makes natural short confirmations ("ja", "nee", "klopt") — the most common turn type in phone conversations — unreliable.

We can share the dual-channel recording and full logs privately on request.

[kkorpal]

Hi @MichelN89, thanks for the super detailed write-up and logs! We're actually already tracking some related VAD edge cases for this model, so your production evidence is incredibly helpful. I'm taking this directly to the Live API engineering team to include in their active investigation.

[mcomunidadvazquez-tech]

Nota: utilizamos la API Live a través del WebSocket BidiGenerateContent sin procesar (no este SDK), pero al reportar esto aquí, parece que los informes sobre el comportamiento del modelo de la API Live se gestionan en este repositorio (ver #1894 ). Con gusto lo moveremos a donde corresponda.

Resumen

models/gemini-3.1-flash-live-preview(API en vivo, audio a audio, caso de uso de telefonía) Ignora sistemáticamente las breves intervenciones del usuario (de 1 a 2 segundos) pronunciadas poco después de que el modelo finalice su turno . No inputTranscriptionse produce ningún mensaje para ellas, no se abre ningún turno, no se devuelve ningún error; la sesión simplemente permanece en silencio hasta que el usuario produce una intervención más larga . Quienes llaman perciben esto como si "el agente se hubiera ido repentinamente" y cuelgan.

Evidencia (convocatoria de producción, 24/08/2026, ~08:01–08:02 UTC)

Cronología reconstruida a partir de nuestros registros del puente de mando + la grabación de la llamada de doble canal:

t (rel) Canal Evento
60,8 s modelo La modelo termina su turno (pregunta "¿debo continuar?"), turnCompleterecibió
61–62s llamador "Ja, dat hoort." — habla clara (verificado, ver más abajo) → sin activación del VAD, sin transcripción, sin respuesta
68-69s llamador "¿Ben je er nog?" — discurso claro → ignorado de nuevo
74–79s llamador Frase de queja más larga (~5 s) → finalmente se activa el turno, el modelo responde normalmente
Tres verificaciones independientes:

1. El audio se entregó de forma continua. Nuestro puente transmite fragmentos PCM16/16k de 20 ms (convertidos desde audio de telefonía μ-law de 8 kHz) a través de realtimeInput.audio; los contadores de envío muestran ~50 fragmentos/seg ininterrumpidos durante toda la ventana, sin errores de WS, sin reconexiones, sin goAway.
2. El discurso es objetivamente claro. El mismo audio entrante (de la grabación de la llamada, del mismo tramo) se gemini-3.7-flash generateContenttranscribe perfectamente, incluyendo las marcas de tiempo: [0:01-0:03] (clear speech): "Ja, dat hoort."/ [0:09-0:10] (clear speech): "Ben je er nog?". Por lo tanto, el propio STT de Gemini entiende este audio; solo la puerta de enlace VAD en vivo que está delante lo descarta.
3. El dispositivo VAD estaba configurado con la máxima sensibilidad en el momento de la llamada:

"realtimeInputConfig": {
"automaticActivityDetection": {
"startOfSpeechSensitivity": "START_SENSITIVITY_HIGH",
"endOfSpeechSensitivity": "END_SENSITIVITY_HIGH",
"prefixPaddingMs": 300,
"silenceDurationMs": 800
}
}
El mismo patrón se produjo en llamadas anteriores (por ejemplo, 22/08/2026: un breve "Ja." que confirmaba una pregunta fue ignorado durante 25 segundos hasta que la persona que llamaba pronunció una frase más larga), también con la configuración VAD predeterminada, por lo que no se debe a esta configuración en particular.

Configuración

• Modelo: models/gemini-3.1-flash-live-preview, WebSocket sin procesarv1beta.GenerativeService.BidiGenerateContent
• Entrada de audio: PCM16@16kHz(sobremuestreado a partir de telefonía μ-law de 8 kHz), fragmentos de 20 ms, enviados continuamente (sin control del lado del cliente)
• responseModalities: ["AUDIO"], speechConfig.languageCode: "nl-NL", transcripción de entrada/salida habilitada ( languageCodes: ["nl-NL"]), sessionResumption+ contextWindowCompression.slidingWindowhabilitado, ~15 declaraciones de funciones + googleSearch
• Instrucciones del sistema ~9k caracteres

Esperado

Una declaración clara de 1 a 2 segundos después del turno del modelo debería abrir un turno del usuario (o como mínimo producir un inputTranscription), especialmente con

daily-repo-status.md

START_SENSITIVITY_HIGH.

Actual

Las frases cortas que siguen a un turno de palabra se omiten tácitamente; las frases más largas funcionan. Esto hace que las confirmaciones breves y naturales ("ja", "nee", "klopt"), el tipo de turno más común en las conversaciones telefónicas, no sean fiables.

Si lo solicita, podemos compartir la grabación de doble canal y los registros completos de forma privada.