Conflicting definitions of prefixPaddingMs in the Gemini Live API documentation

Gemini API
1

Could you please clarify the exact behavior of automaticActivityDetection.prefixPaddingMs? Two official documentation pages appear to define this parameter differently.

Source 1: Live API capabilities guide

Under “Understanding VAD parameters and their impact on quality,” the guide defines prefixPaddingMs as:

“The amount of audio to include before speech is detected.”

It describes this as a look-back or pre-speech buffer that prevents the beginning of an utterance from being clipped. The guide also says that setting it to 0 may clip the beginning of words.

This description suggests that prefixPaddingMs controls how much audio from before the VAD trigger is included in the user’s speech turn.

Source 2: Live API WebSockets API reference

The AutomaticActivityDetection reference defines prefixPaddingMs as:

“The required duration of detected speech before start-of-speech is committed.”

It further explains that a lower value makes start-of-speech detection more sensitive, allows shorter speech to be recognized, and increases the probability of false positives.

This description suggests that prefixPaddingMs is a minimum sustained-speech or confirmation duration, not simply a pre-speech audio buffer.

These definitions describe materially different behaviors. For example, with:

{
  "prefixPaddingMs": 300
}

The capabilities guide appears to imply that Gemini detects speech and includes approximately 300 milliseconds of preceding audio in the turn.

The API reference appears to imply that Gemini must observe approximately 300 milliseconds of detected speech before committing the start-of-speech event. That could delay barge-in by approximately 300 milliseconds and prevent shorter sounds or utterances from being recognized.

Could you please clarify the following?

  1. Does prefixPaddingMs control the amount of audio retained from before the initial speech-detection point?

  2. Does it control how long speech must persist before start-of-speech is committed?

  3. Does setting it to 300 ms delay the start-of-activity or interruption event by approximately 300 ms?

  4. If start-of-speech is committed after that confirmation period, is the buffered audio from the beginning of the utterance still included in the model’s input?

  5. Does the parameter intentionally serve both purposes: speech-start confirmation and prefix buffering?

  6. If behavior differs between Gemini Live models or API versions, could you specify those differences?

  7. What are the default value and supported minimum and maximum values?

It would be helpful if both documentation pages could be updated with one precise definition and a timeline example showing when candidate speech begins, when start-of-speech is committed, and which audio is included in the resulting turn.

Thank you.