Speech API python client library method `streaming_recognize()` doesn't return a result with `is_final` set to True

[nikaided]

In which file did you encounter the issue?

• https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/speech/microphone/transcribe_streaming_infinite.py

Did you change the file? If so, how?

I have changed the line 299

 config = speech.RecognitionConfig(
        encoding=speech.RecognitionConfig.AudioEncoding.LINEAR16,
        sample_rate_hertz=SAMPLE_RATE,
        language_code="en-US",
        max_alternatives=1,
    )

into

 config = speech.RecognitionConfig(
        encoding=speech.RecognitionConfig.AudioEncoding.LINEAR16,
        sample_rate_hertz=SAMPLE_RATE,
        language_code="ja-JP",
        max_alternatives=1,
    )

Describe the issue

streaming_recognize() method doesn't work properly. For even when a speaker utters a simple greeting like こんにちは in a very silent environment, this method returns StreamingRecognizeResponse object with a result of is_final == False. And always returns a result with is_final set to True exactly 90 seconds later.
this doesn't happen when the language is English or Chinese.
The same thing also happens in transcribe_streaming_infinite_v2.py

I am not sure if this report should be post here for this seems to be more internal problem.
Appreciate any help or clues anyways.

[madhavmadupu]

This issue occurs because the Speech-to-Text API's default endpointing (silence detection) algorithm is less aggressive for certain languages like Japanese (ja-JP) compared to English. In quiet environments, the server may wait for a significant period of silence or until a internal timeout (often 90 seconds) is reached before marking a result as is_final.

To resolve this and make the transcription responsive, you should configure the API to use a Voice Activity Timeout (in V2) or use the Single Utterance mode (in V1).

---

Suggested Solution

The delay in is_final results for Japanese is a known behavior where the server-side endpointing is less sensitive in quiet environments. To fix this, you can apply the following changes to the sample scripts:

1. Fix for transcribe_streaming_infinite_v2.py

The V2 API allows you to explicitly set a speech_end_timeout. This forces the server to return a final result after a specified duration of silence (e.g., 1–2 seconds).

Update the streaming_config section:

# In transcribe_streaming_infinite_v2.py
from google.protobuf import duration_pb2

# ... inside the transcription logic ...

streaming_config = cloud_speech.StreamingRecognitionConfig(
    config=recognition_config,
    # Add this block to control endpointing
    voice_activity_timeout=cloud_speech.StreamingRecognitionConfig.VoiceActivityTimeout(
        speech_end_timeout=duration_pb2.Duration(seconds=2)
    ),
)

2. Fix for transcribe_streaming_infinite.py (V1)

Since the V1 API does not support granular timeouts, the best way to handle this in the "infinite" sample is to set single_utterance=True. Because this script is already designed to restart the stream in a loop, setting this flag will make it return is_final=True immediately after a phrase and then seamlessly restart.

Update the streaming_config section:

# In transcribe_streaming_infinite.py

streaming_config = speech.StreamingRecognitionConfig(
    config=config, 
    interim_results=True,
    single_utterance=True  # Forces the API to 'finalise' after one utterance
)

3. Recommended Model Change

For short greetings like "こんにちは", switching from the default model to a more specific one can also help the engine "commit" to results faster.

# For V1
config = speech.RecognitionConfig(
    # ...
    language_code="ja-JP",
    model="latest_short", # Use the latest short-form model for better endpointing
)

Why this works:

• Voice Activity Timeout (V2): Manually overrides the server's silence detection threshold.
• Single Utterance (V1): Tells the API that the request is for a command or short phrase, triggering an earlier "final" result. Since the transcribe_streaming_infinite script manages restarts, this allows for continuous but responsive transcription.

---

Note to the user: If you are submitting this as a PR, I recommend updating the v2 sample with the voice_activity_timeout as it is the most modern and robust way to handle language-specific latency.