Gemini 3.1 Flash TTS Preview returns HTTP 200 with empty content and finishReason OTHER for Hebrew TTS prompt

[yooo1999]

I’m seeing intermittent no-audio responses from Gemini TTS preview.

For the same request, the API sometimes returns HTTP 200 with:

{
  "content": {},
  "finishReason": "OTHER",
  "usageMetadata": {
    "promptTokenCount": 713,
    "candidatesTokenCount": 5516
  }
}

There is no inlineData.data audio payload, even though usageMetadata reports audio tokens.

Later, the exact same request can succeed with:

{
  "finishReason": "STOP",
  "usageMetadata": {
    "promptTokenCount": 713,
    "candidatesTokenCount": 4925
  }
}

and includes valid inlineData.data audio.

Context:

• Model: gemini-3.1-flash-tts-preview
• Endpoint: generateContent
• Modality: responseModalities: ["AUDIO"]
• Voice: Kore
• Input: Hebrew text
• Client: reproduced both from Python GenAI SDK and curl

Minimal repro / discussion:
https://discuss.ai.google.dev/t/gemini-tts-preview-returns-http-200-with-usagemetadata-but-no-audio-payload/145337

Question:
Is finishReason: OTHER with empty content expected/retryable for Gemini TTS preview, or does it indicate a prompt/request issue?

[kkorpal]

Hi @yooo1999, thanks for the detailed report and for linking the discussion thread! I will bring this directly to the core API engineering team to investigate the stability of the TTS preview encoding pipeline. Thanks.

[ibmeister]

@Giom-V @thorwebdev @kkorpal any updates?

[kkorpal]

Hey @yooo1999, we re-tested this against gemini-3.1-flash-tts-preview with Hebrew text prompts, and all 5 attempts returned Finish Reason: STOP with valid audio payloads and no errors.

It looks like the backend issue has been fixed. Are you still encountering any intermittent failures on your end, or is this working smoothly for you now?

[yooo1999]

Hey @kkorpal , thanks for following up and re-testing!

I ran automated benchmark tests comparing Hebrew and English across multiple request lengths to verify the fix. Here are the findings:

🛠️ Environment & Technical Details

• Model: gemini-3.1-flash-tts-preview
• Endpoint: v1beta/models/gemini-3.1-flash-tts-preview:generateContent
• Voice: Kore (speechConfig.voiceConfig.prebuiltVoiceConfig.voiceName)
• Modality: responseModalities: ["AUDIO"]
• Environment: Python 3.12 (tested both direct REST via urllib and google-genai Python SDK)
• Audio Format: Raw PCM (audio/L16;rate=24000, mono) decoded from inlineData.data
• Analysis: Calculated RMS volume across 3 equal sections (Start / Mid / End) to evaluate volume consistency over time.

---

📊 Test Results

1. Hebrew Prompts (~1,600 chars, ~2.7 min audio)

• 10 test iterations:
  • 9/10 passed with finishReason: "STOP"
  • 1/10 reproduced the bug: Returned HTTP 200 after 139s with finishReason: "OTHER" and empty content (no inlineData.data audio payload, despite reporting candidatesTokenCount).
  • Volume Fade Issue: On successful long outputs, there is a progressive volume drop toward the end of the audio:
    • Average End-to-Start Volume Ratio: 53.7%
    • Worst case: Volume dropped to 24.6% of initial volume (barely audible).

2. English Prompts (~2,350 chars, ~2.8 min audio)

• 7 test iterations:
  • 6/7 passed with finishReason: "STOP" (0 instances of finishReason: "OTHER").
  • 1 request timed out after 720s.
  • Volume Fade Issue: Also present, though slightly less severe than Hebrew:
    • Average End-to-Start Volume Ratio: 68.3%
    • Minimum ratio: 50.1%

3. Short & Medium Prompts (< 1,000 chars / < 1 min audio)

• 100% stable in both English and Hebrew (no OTHER finish reason, no noticeable volume decay, ratio ~0.85–1.08).

---

📌 Summary

1. finishReason: "OTHER" with empty content: The failure rate has significantly decreased compared to earlier, but it is intermittent on long prompts (~1.5k+ chars), failing ~10% of the time.
2. Volume degradation: On long generation outputs (> 2.5 minutes), the audio consistently fades out in amplitude toward the end (especially prominent in Hebrew).