gemini-3.5-live-translate-preview consistently truncates the last words of translated audio output

Gemini API
,
1

Environment

  • Model: gemini-3.5-live-translate-preview
  • API access: WebSocket (wss://generativelanguage.googleapis.com/ws/google.ai.generativelanguage.v1beta.GenerativeService.BidiGenerateContent)
  • Client: Chrome extension (Manifest V3), tested on Chrome stable
  • Config:

json

  {
    "setup": {
      "model": "models/gemini-3.5-live-translate-preview",
      "generationConfig": { "responseModalities": ["AUDIO"] },
      "translationConfig": { "targetLanguageCode": "pt-BR", "echoTargetLanguage": true },
      "inputAudioTranscription": {},
      "outputAudioTranscription": {}
    }
  }
  • Audio format: input PCM 16-bit 16kHz mono (as required); output PCM 16-bit 24kHz mono (as returned)

Product context

I’m building DuoVox / Meet Tradutor Pro, a Chrome extension that provides real-time bidirectional speech translation for video-conferencing platforms (Google Meet, Microsoft Teams, Zoom web client). The extension has two independent modules, both routed through the Gemini Live API:

  1. “Sua Voz” (Your Voice): captures the local user’s microphone (PT-BR), sends to Gemini with translationConfig.targetLanguageCode: "en", and pipes the translated English audio back into Meet as a virtual mic input (via MediaStreamDestination intercepting getUserMedia).
  2. “Captura de Áudio” (Audio Capture): captures the remote speakers’ audio from the tab via chrome.tabCapture, sends to Gemini with translationConfig.targetLanguageCode: "pt-BR", and plays the translated Portuguese audio locally through the user’s speakers via an offscreen document (to avoid the tabCapture re-capturing the translation and creating an echo loop).

Both modules use the same WebSocket protocol and the same gemini-3.5-live-translate-preview model. The Sua Voz module works reliably. The Captura de Áudio module has a consistent, reproducible issue described below.

Symptom

The last one or two words of nearly every translated sentence are cut off in the audio output. This is not intermittent — it happens on the vast majority of sentences (~90-95% in my testing, across sessions of a few minutes each).

Example:

  • Original (EN): “Hello Daniel, how are you? My name is Daniel Rodrigues.”
  • Expected translation (PT-BR): “Olá Daniel, como você está? Meu nome é Daniel Rodrigues.”
  • Actual audio output: “Olá Daniel, como você está? Meu nome é Daniel Rodri…” (audio ends abruptly mid-word or mid-final-word)

The outputTranscription text field usually contains the complete sentence, but the modelTurn.parts[].inlineData.data (base64 PCM audio) stops before the last word finishes decoding.

What I’ve verified is NOT the cause

I’ve spent considerable time isolating this and can rule out the following client-side causes:

  1. Not a playback scheduling issue. I’ve tested three separate playback strategies in the offscreen document:

    • AudioBufferSourceNode scheduled with a running playTime cursor (chunks back-to-back, no gaps)
    • src.start() with no scheduling (Sua Voz style — chunks play immediately as they arrive)
    • MediaStreamAudioDestinationNode piped through an HTMLAudioElement (jitter buffer)
    • Hybrid (playTime + MediaStream sink)

    All strategies produce the same truncation at the end of sentences. The truncation is in the PCM data itself, not in how I’m playing it.

  2. Not a silence-gate issue on the output side. I initially had an RMS-based silence gate on the output PCM frames (dropping frames below a threshold to avoid drift). Removing the gate entirely and playing every single frame the server sends (including all-zero silence frames) does not restore the missing tail — because the missing audio was never sent by the server.

  3. Not a WebSocket connection issue. The WebSocket stays open, there are no disconnections during the truncated sentences, and subsequent sentences translate normally.

  4. Not an issue with my custom code being incorrect vs. the official pattern. I’ve verified my message handling against the official docs (ai.google.dev/api/live and ai.google.dev/gemini-api/docs/live-api/live-translate) and against community references. My client processes every modelTurn.parts[].inlineData message it receives — the last chunk simply arrives shorter than expected, and no subsequent chunk with the missing tail ever arrives.

What I have observed

  • I do not receive any serverContent.interrupted: true around the truncation events.
  • I observe serverContent.turnComplete: true inconsistently — sometimes it arrives, sometimes it doesn’t. When it does arrive, it arrives shortly after the last audio chunk, which is already truncated.
  • The truncation happens in the audio stream while the outputTranscription text is often complete or nearly complete. So the model “knows” the full translation textually, but the audio synthesis of the last words is not delivered.

Related known issues

This pattern strongly resembles known open issues in the Native Audio dialog models, though I’m reporting it here because those issues do not specifically cover gemini-3.5-live-translate-preview:

  • googleapis/js-genai#707 — premature turnComplete despite incomplete content (open ~8 months, ~40 confirmations)
  • google-gemini/live-api-web-console#117 — model stops midway while speaking
  • googleapis/python-genai#2117 — mid-sentence audio truncation on Native Audio (Feb 2026)

None of these track gemini-3.5-live-translate-preview specifically. I’m posting here to (a) confirm whether the Live Translate model exhibits the same class of bug, and (b) get official acknowledgment or a workaround.

Questions

  1. Is gemini-3.5-live-translate-preview affected by the same premature-truncation behavior reported for the Native Audio models?
  2. Is there any server-side configuration (via translationConfig, generationConfig, or setup fields) that mitigates this in the current preview?
  3. Are there any client-side signals I should be watching for that indicate the model is about to end a turn early, so I could at least detect it and potentially re-send the input for the truncated segment?
  4. Is a fix or improvement to this behavior on the roadmap for the live-translate preview specifically?

Reproducibility

This happens on any English → Portuguese translation session with continuous speech, using the exact config above. I can share sanitized WebSocket logs (input/output message metadata, no audio payloads) if that would help debug.

Thank you.