Gemini Live Mic Test

Gemini Live Mic Test: Noise Floor, Clipping and Latency Check

In Gemini Live, speech moves through a streaming audio pipeline with automatic gain control applied on Google's servers. AGC normalizes your input volume before the speech recognition stage¹, which means moderate noise floors that would cause errors in a fixed-gain pipeline are handled more robustly. Yet AGC has limits: when the noise floor exceeds −35 dBFS (the Very Noisy range on the Noise Floor Grade), gain normalization amplifies background noise proportionally, pushing it into the same amplitude range as speech and causing the model to interpret noise as speech activity.

The Frequency Response display reveals an important consideration for Gemini Live: the service processes audio optimized for the 300 Hz–3.4 kHz telephone bandwidth range², though wider input is accepted. Microphones that roll off below 200 Hz or above 8 kHz still work effectively, making noise floor and clipping performance more important than frequency response width. The Clap Latency Test is particularly relevant for Gemini Live's conversational turn-taking: the service uses interruption-capable processing, and high browser-side latency creates perceptible hesitation in the conversation flow.

Noise floor requirements

Gemini Live's AGC normalizes input amplitude but cannot separate speech from noise when both occupy similar frequency bands and amplitude ranges. At noise floor levels between −45 dBFS and −35 dBFS, AGC amplifies the combination of speech and noise together, reducing the speech-to-noise ratio at the point of recognition rather than improving it³. Furthermore, sustained noise sources that repeat rhythmically (fan blades, air conditioning cycles) can confuse the speech activity detector, causing the service to begin processing and then abort mid-response. A Noise Floor Grade of Good or Excellent eliminates this risk reliably. The key threshold to remember is that AGC becomes counterproductive when the noise floor exceeds −45 dBFS, because at that point the gain normalization stage amplifies background noise proportionally with your voice rather than isolating the speech signal, which degrades the speech-to-noise ratio that the recognition model depends on for accurate transcription.

Why AGC cannot fix a poor noise floor

Automatic gain control on Google's servers adjusts the overall amplitude of the incoming audio stream to normalize volume levels across different microphones and distances, but it processes the combined signal of speech and noise together without the ability to distinguish between the two. When background noise occupies the same frequency bands as your voice, raising the gain to make speech louder also makes the noise louder by the same amount, which means the speech-to-noise ratio at the recognition stage remains unchanged despite the AGC adjustment.

This is why the practical target remains a Noise Floor Grade of Good or better before any Gemini Live session, because once the floor crosses the −45 dBFS point the AGC stage begins scaling noise upward alongside your voice rather than isolating it. A clean input delivered to the server gives the recognition model a stable speech-to-noise ratio that no amount of server-side normalization can reconstruct after the fact.

Latency and interruption handling

Gemini Live supports interruption, meaning you can speak over the model's response to redirect the conversation. This feature works best when browser-side audio latency is below 80ms. At higher latency, the interrupt signal reaches the server after additional model output has already been generated, making clean interruptions less predictable. The Clap Latency Test measures the full browser audio round-trip. Keeping this below 60ms gives Gemini Live's interruption handling the tightest possible timing window from your side of the connection.

When you speak over Gemini Live's output to change the subject or correct a misunderstanding, your interrupt audio must travel through the browser's WebAudio pipeline, across the network, and into the server's streaming inference loop before the model registers that a new speaker has taken control. Every millisecond of browser-side latency adds directly to this chain, which means a Clap Latency Test result of 90ms creates a noticeably longer window where the model continues generating its original response before your redirect arrives and gets processed.

Clipping and frequency response

AGC on the server side cannot recover samples that were clipped before transmission. Once the waveform is saturated at 0 dBFS in the browser's audio stream, the sample value is corrupted before leaving your device⁴. The Clipping Detector running in the browser is therefore the correct place to catch this: it flags clipping before the signal reaches Gemini Live's servers. Frequency response outside the core speech range matters less for Gemini Live than for wideband audio AI services, because the recognition model targets the 300 Hz–3.4 kHz band most heavily.

Why clipped samples bypass AGC recovery entirely

Server-side AGC operates on the digital samples it receives, adjusting their amplitude up or down to normalize the overall level. But when a sample is already pinned at 0 dBFS because of clipping in the browser's audio pipeline, the AGC stage has no information about what the original waveform peak looked like before it was truncated. The saturated sample value is the only data available, so the AGC can only scale a corrupted value that no longer represents the original sound pressure wave. This is why the Clipping Detector in the browser catches the problem at the only point where the original signal is still intact and the damage can actually be prevented.

Gemini Live's frequency range and microphone selection

Comparing microphone types for Gemini Live reveals that frequency response width matters less than noise floor and clipping performance. The service processes audio most effectively in the 300 Hz–3.4 kHz telephone bandwidth range, where its speech recognition model is most heavily weighted. A dynamic microphone with a frequency response that rolls off above 12 kHz still covers this band fully, while its lower sensitivity compared to a condenser produces a better Noise Floor Grade in noisy environments because it rejects ambient room sound more effectively at equivalent gain settings.

At equivalent OS gain settings, a dynamic microphone produces a quieter Noise Floor Grade than a condenser in the same room because its capsule is less sensitive to ambient sound⁵. The useful comparison is not at identical gain settings but at gain-matched conditions: set each microphone to the OS gain level that achieves an identical Noise Floor Grade result. Condenser microphones may require substantially lower gain to match a dynamic microphone's noise floor in a live room.

Broadcast-style dynamic microphones typically produce Noise Floor Grades of Excellent in the same room where a budget condenser might show Noisy, because the dynamic's lower sensitivity requires gain levels where room noise contributes less to the measurement. For Gemini Live sessions in an office environment with background noise, a dynamic microphone often outperforms a condenser despite the condenser's theoretically better specifications: the lower sensitivity advantage overcomes the condenser's lower self-noise when room noise is the dominant floor source.

Using multiple Noise Floor Grade runs to identify AGC instability

Gemini Live's server-side AGC can produce inconsistent behavior when your noise floor sits close to the edge of what AGC handles cleanly. If your Noise Floor Grade shows more than 6–8 dBFS variation across five consecutive runs in unchanged conditions, OS-level Automatic Gain Control may be adjusting the input amplification between runs⁶, which produces exactly this kind of run-to-run variation and causes the service to receive audio at fluctuating amplitudes.

Identifying AGC behavior from test variation

Run the Noise Floor Grade five times without changing any settings or room conditions. If the first two runs return Good and subsequent runs return Excellent, the room just needed to settle. If the variation is persistent and unpredictable across all five runs, spot Gemini Live AGC instability and check whether Windows AGC is enabled in your audio device properties. Windows AGC adjusts input gain dynamically and creates this pattern of test-to-test variation. Disabling Windows AGC and rerunning five tests confirms whether the variation disappears: if it does, OS AGC was the source, not the room or the server's processing.

When to use this

Use this check before Gemini Live conversations when you are in an environment with variable background noise, especially when AGC behavior feels inconsistent or when the service misinterprets background sounds as speech.

Examples

Noise floor −40 dBFS — AGC amplifies fan noise to speech level, causing false activations

Fan switched off: noise floor −64 dBFS (Excellent) — clean conversation without false starts

Clipping badge triggers on loud consonants — Gemini Live cuts off and restarts recognition

OS gain reduced 12 dB: no clipping, Excellent noise floor — uninterrupted sessions