We are seeing intermittent silent stalls with two simultaneous Gemini Live transcription sessions.
Environment
- Model:
gemini-3.5-transcribe-live
- Gemini Developer API
google-genai 2.20.0
- Python 3.14.4 on macOS
- Two simultaneous Live sessions using API keys from separate Google Cloud projects
- Input: 16-bit mono PCM at 16 kHz, streamed in 100 ms chunks
- Both audio channels are captured from one synchronized stereo device clock
Observed behavior
One or both sessions intermittently stop returning all server messages while the WebSocket/TCP connection remains established. send_realtime_input continues successfully and audio chunk counters continue increasing.
During a stall:
- no exception is raised
- no GoAway message is received
- no 429 or 5xx response is received
- audio capture continues
- RMS and peak levels remain active
- capture queue overruns remain zero
- send timeouts remain zero
The other simultaneous session may continue transcribing normally. Restarting only the affected Live session immediately restores transcription.
Connectivity checks
- 20 of 20 normal pings returned with 0% packet loss
- 20 of 20 1,200-byte pings returned with 0% packet loss
- authenticated REST model checks returned HTTP 200 for both projects
- DNS resolution was healthy
- the local network tunnel showed zero input errors, output errors, or drops
- round-trip time was high but stable at approximately 279 ms
- the two active port-443 TCP connections remained ESTABLISHED during the silent condition
- older Google port-443 sockets sometimes remained in CLOSE_WAIT after reconnects
Expected behavior
The sessions should continue returning interim and final transcription events while speech is present, or explicitly close/error if they can no longer process audio.
Questions
- Can
gemini-3.5-transcribe-live accept audio while silently ceasing all server responses?
- Are there known issues with two concurrent Live transcription sessions using separate Google Cloud projects?
- Is session resumption required for this model before the documented connection limit?
- Is there a session or request identifier we can log so Google can trace the affected backend connection?
- Could
google-genai 2.20.0 leave Live sockets in CLOSE_WAIT after reconnect?
Hi @andrewwingert,
When using gemini-3.5-transcribe-live, transcription events are emitted in response.server_content.input_transcription.text rather than response.server_content.model_turn. Because model_turn remains empty for speech-to-text streams, checking model_turn.parts causes transcripts to be ignored.
Additionally, non-speech signals (like pure sine wave tones) and silence are filtered out by voice activity detection while keeping the socket open. Ensure your session setup includes input_audio_transcription=types.AudioTranscriptionConfig(language_codes=[]) as demonstrated in the Live Transcription Guide.
Thanks, Payal. We already enable input_audio_transcription and consume the transcription fields from response.server_content. We do not inspect model_turn.
This is a simplified version of our current receiver:
config = types.LiveConnectConfig(
response_modalities=["TEXT"],
input_audio_transcription=types.AudioTranscriptionConfig(
language_codes=[],
mode="VERBATIM",
),
)
async with client.aio.live.connect(
model="gemini-3.5-transcribe-live",
config=config,
) as session:
async def send_audio(chunk: bytes):
await session.send_realtime_input(
audio=types.Blob(
data=chunk,
mime_type="audio/pcm;rate=16000",
)
)
async def receive_transcripts():
async for response in session.receive():
print("server response received")
content = response.server_content
if not content:
continue
interim = content.interim_input_transcription
final = content.input_transcription
if interim and interim.text:
print("INTERIM:", interim.text)
if final and final.text:
print("FINAL:", final.text)
The failure appears to happen before transcription-field parsing: when a session stalls, the async for response in session.receive() loop stops yielding response objects entirely.
During the stalled condition:
- Human speech is present; this is not silence or a test tone.
- Audio RMS and peak levels remain active.
send_realtime_input() continues completing successfully.
- The number of audio chunks sent continues increasing.
- No send timeout, exception,
GoAway, 429, or 5xx is received.
- The affected session’s server-response counter and
last_response_at timestamp stop changing.
- The second simultaneous session may continue returning transcripts normally.
- Restarting only the affected session immediately restores transcription.
Therefore, this does not appear to be caused by reading model_turn or by VAD filtering non-speech audio.
We are using google-genai==2.20.0 with two concurrent gemini-3.5-transcribe-live sessions, using API keys from separate Google Cloud projects.
Is there a Live API session ID, request ID, WebSocket identifier, or additional SDK debug logging we can capture so the affected backend connection can be traced?
We can provide timestamps and telemetry from the affected sessions if that would help reproduce the issue.