Mic Test for AI Voice Assistants and Speech-to-Text

Mic Test for AI Voice Assistants and Speech-to-Text

Every voice assistant listens through the same chain: your microphone, your operating system, then the assistant's own speech detection. When an assistant cuts you off, answers before you finish or keeps mishearing a word, the cause is usually something you can measure in that chain before you start talking. Three readings cover most of it: how loud the room is when you are silent, whether your loudest words hit the digital ceiling, and how much delay your audio path adds.

The first section sets those three targets once, because they apply to every assistant. The sections after it cover only what differs: how each assistant decides you have stopped talking, where its audio is processed and which setting it is most sensitive to.

The three readings every assistant needs

Aim for a Noise Floor Grade of Good or Excellent, which on this tool means a silent room reads below −50 dBFS. Assistants that detect speech by level, which most live voice modes do, compare your voice with the room. A Noisy grade (−50 to −40 dBFS) leaves less contrast, so a fan or a conversation next door can count as speech, and quiet word endings can count as silence. Fix the room before you touch any setting: closing a window, switching off a desk fan or moving the microphone closer to your mouth usually shifts the grade more than any software option.

Finding a safe gain window

Gain has two limits. Too low, and your voice sits close to the noise floor. Too high, and loud consonants clip at 0 dBFS, which flattens the waveform and adds distortion across the whole spectrum.¹ Start with the Noise Floor Grade at your normal gain, then run the Clipping Detector for about 20 seconds while you speak at your loudest normal volume, including hard sounds like "p" and "b". If the badge appears, lower the gain a few steps and repeat. Then lower it a little more, because excited speech peaks higher than a calm test sentence.

Latency and Bluetooth

The Clap Latency Test grades the round trip through your browser and OS: under 60 ms is Good, and 60 to 100 ms is Noticeable. That delay matters for live assistants you can interrupt, because your interruption reaches the service later. Bluetooth headsets add the most. When a headset microphone is active, many headsets switch to the hands-free profile, whose narrowband mode carries telephone-quality audio, so the Frequency Response display drops off sharply above about 4 kHz.² A wired or USB microphone avoids both problems.

Speaker bleed

Any assistant that talks back can hear itself. If its reply plays through speakers near an open microphone, the reply enters your input and can trigger a false interruption or a false wake word. Record an Echo Loopback while audio plays from your speakers to hear how much reaches the microphone, and use headphones when you can.

Headphones remove that path completely rather than reducing it, which is why they solve the problem on every assistant that speaks aloud. If you have to keep speakers, turn their volume down and move the microphone off the speaker axis, so the reply reaches the capsule at an angle its pickup pattern already rejects.

ChatGPT Voice Mode Mic Test

For ChatGPT Advanced Voice Mode, GPT-4o's audio model processes audio waveforms directly for end-to-end voice handling.¹ Unlike previous OpenAI voice implementations that transcribed speech before generating a text response, Advanced Voice Mode keeps the audio path central to turn-taking and response timing. Background noise that a traditional speech-to-text engine might suppress through noise reduction degrades the interrupt detection mechanism, the part of the system that determines when you have stopped speaking and when to respond.

The noise floor threshold that matters for ChatGPT Advanced Voice Mode is approximately −50 dBFS or better. Above that level, background noise competes with the active speech signal in a way that confuses the end-of-speech detector, causing the model to respond prematurely or to miss the end of your sentence. Latency below 60ms round-trip (as measured by the Clap Latency Test) ensures that the model's audio output and your subsequent speech do not overlap with noticeable delay.² Run the Noise Floor Grade, Clipping Detector, and Clap Latency Test as your pre-session checks before any Advanced Voice Mode conversation.

Background noise and Advanced Voice Mode speech detection

Advanced Voice Mode processes audio in near real-time without a dedicated noise gate stage visible to the user. When background noise reaches the −40 dBFS range (the threshold the Noise Floor Grade labels Noisy), the model's speech activity detection activates for noise events as well as speech, producing false turn-taking signals. Furthermore, continuous background noise above −45 dBFS compresses the effective dynamic range available to GPT-4o's audio model for distinguishing your speech from silence.

Corrective actions that shift the grade fastest

Achieving a Noise Floor Grade of Good or Excellent before starting a voice session eliminates this problem reliably. If your initial reading is Noisy, take one corrective action, then retest before the session. Closing a window, turning off a nearby fan, or moving the microphone 10 cm closer to your mouth are the three fastest improvements. Each action alone can shift the grade by 5 to 10 dBFS. Running the test after each single change tells you which action had the most impact, so you know what to prioritize next time without guessing.

Target a Noise Floor Grade of Good or better, which corresponds to roughly −50 dBFS or lower, because Advanced Voice Mode's interrupt detection begins to misread background noise above that level. A single high-impact change that reaches the Good threshold is enough to clear a session, so you do not need every environmental fix in place before starting the conversation.

Interrupting ChatGPT mid-response

ChatGPT Advanced Voice Mode supports natural conversation with human-speed turn-taking, including the ability to interrupt the model mid-response.³ Round-trip latency above 80ms (the upper boundary of the Clap Latency Test's Good grade) adds a perceptible delay to the interrupt detection loop. Building on this, the model buffers audio on its end to manage network jitter, but the browser-to-network path latency adds on top of that server buffer. Keeping your Clap Latency Test result below 60ms eliminates the browser-side audio stack as a latency contribution.⁴

When you interrupt Advanced Voice Mode, the interrupt signal must reach OpenAI's servers before the next audio frame is generated and streamed back to your browser. If your browser-side latency is 80ms or higher, the server has already committed to additional output frames by the time your interrupt arrives, which means the model continues speaking for a noticeable window before it registers that you have started talking over it. Reducing browser-side latency tightens this window and makes the conversational back-and-forth feel closer to a natural phone call where both participants can react instantly.

Clipping and the speech band GPT-4o listens to

GPT-4o's audio model processes speech in the 80 Hz–8 kHz fundamental range where human voice energy is concentrated.⁵ Clipping at 0 dBFS introduces harmonic distortion that extends far above this range, creating an artificial spectral signature that the model processes less effectively. Consequently, the Clipping Detector is particularly important here: even brief clipping during peak consonant sounds corrupts the audio frame the model uses to parse phonemes.⁶ Aim for a Frequency Response display that shows consistent energy through the speech range without sharp peaks indicating gain staging problems.

Unlike traditional pipelines that separate transcription from language processing, GPT-4o's audio model maps raw waveforms directly to semantic representations without an intermediate text stage. This means clipped samples do not just produce a wrong letter in a transcript; they distort the entire audio frame the model uses to determine what was said at that moment. The harmonic artifacts from clipping spread across all frequencies simultaneously, confusing the model's attention mechanism in ways that are fundamentally harder to recover from than a simple noise-floor issue that spectral subtraction could address.

Gain staging for Advanced Voice Mode sessions

Before an Advanced Voice Mode session, the gain staging window that satisfies both the Noise Floor Grade and the Clipping Detector simultaneously defines your safe operating range. For most microphones in a quiet room, this window spans 15–20 dB of gain adjustment: below the lower bound, the Noise Floor Grade is Noisy because the signal is too weak relative to ambient noise; above the upper bound, the Clipping Detector fires during peak consonant sounds. Finding this window before the session prevents the most common cause of recognition errors: gain set too high with frequent clipping, or too low with a poor speech-to-noise ratio.

Using both detectors as a gain staging bracket

Run the Noise Floor Grade at your starting gain and confirm it is Good or Excellent. Then run the Clipping Detector while speaking at your loudest normal voice for 30 seconds, including deliberate plosive consonants. If no badge appears, you are inside the safe window. If the badge appears, reduce gain by 3 dB and repeat the Clipping Detector test. This dual-test approach brackets the gain from both ends and confirms the safe operating point with a single adjustment sequence rather than separate gain searches for each constraint independently.

Reading the Frequency Response display before Advanced Voice Mode

The Frequency Response display shows whether your microphone is delivering speech content in the 80 Hz–8 kHz range that GPT-4o's audio model processes. Speak a sustained vowel while watching the display. Energy should appear consistently across the 200 Hz–4 kHz fundamental speech range. If the display shows a steep drop-off above 4 kHz, your microphone may be in HFP Bluetooth mode or using a narrow-bandwidth codec; switch to a wired connection.⁷

Identifying room problems in the display before a session

The Frequency Response display also reveals room problems that are not visible in the single-number Noise Floor Grade, which is why you should read the ChatGPT voice Frequency Response before every session. A consistent energy spike between 100–200 Hz indicates HVAC noise entering the measurement; a series of regularly spaced dips across the midrange suggests comb filtering from a nearby reflective surface. Either of these may not push the Noise Floor Grade into the Noisy range alone, but they reduce the speech signal quality available to Advanced Voice Mode's audio processing at specific frequency bands where phoneme discrimination depends on consistent spectral content.

When to use this

Run this check before any GPT-4o Advanced Voice Mode conversation, especially in noisy environments, or when you notice the model cutting you off mid-sentence or missing the end of your thoughts.

Examples

Noise floor at −38 dBFS (Noisy) — model interrupts prematurely during pauses in speech

Moved to a quiet conference room: noise floor −62 dBFS (Excellent) — model waits for full sentences

Noise floor −44 dBFS, Clap Latency 75ms — occasional missed turn signals and hesitation

AC switched off, USB microphone moved to direct port: −59 dBFS noise floor, 42ms latency — clean conversation

Claude Voice Mode Mic Test

Claude Voice Mode depends on a speech-to-text stage before response generation. Unlike end-to-end audio models, this pipeline has distinct stages: audio capture, speech recognition, and language model inference.¹ Clipping at the audio capture stage introduces distortion that corrupts the speech recognition stage specifically: the waveform shape the recognition model depends on is destroyed by digital saturation, producing transcript errors that the language model then tries to interpret from damaged input.²

A noise floor below −50 dBFS is the threshold where speech recognition errors from background noise become negligible in Claude's voice pipeline for standard accents and speaking rates. Above that level, error rates in the transcription stage increase gradually, though they rarely become catastrophic until the floor exceeds −40 dBFS. The Noise Floor Grade, Clipping Detector, and Frequency Response display are the three tests to run before a voice session. Specifically, ensure the Clipping Detector shows no badge during your loudest normal speech, and that the Noise Floor Grade reads Good or Excellent.

Room noise before server-side transcription

Claude's voice pipeline transcribes audio before the language model processes it, and that transcription happens on Anthropic's servers rather than on your machine: the docs state that recorded audio is streamed to Anthropic for transcription and is never processed locally.³ Background noise that sits between −50 dBFS and −40 dBFS (the Noisy range on the Noise Floor Grade) reduces transcription accuracy by competing with the speech signal in critical frequency bands. Consonants, particularly the sibilant frequencies between 3–8 kHz, are most affected because their energy is weaker relative to fundamental vowel frequencies. Furthermore, sustained background noise causes the speech recognition model to allocate computational attention to modeling noise rather than speech, which reduces confidence scores on phoneme-to-word mapping.

Sibilant sounds like "s," "f," and "sh" produce their distinguishing acoustic energy in the 3 to 8 kHz range, where amplitude is naturally 15 to 25 dB below the fundamental vowel energy concentrated below 1 kHz.⁴ When background noise fills this upper frequency band, the speech recognition model receives a signal where the noise floor and the sibilant energy occupy the same amplitude range, making it impossible to distinguish between a genuine "s" sound and a noise burst that happens to have similar spectral character. Running the Noise Floor Grade before each session catches this problem before it manifests as repeated transcription errors on the most common consonants in English.

Turn-taking with silence detection and push-to-talk

Claude Voice Mode responds after your speech turn ends, using silence detection to identify turn boundaries. Claude Code's dictation mode makes the same assumption explicitly: recording runs while the push-to-talk key is held and stops when you release it, which is a fixed turn boundary rather than an inferred one.⁵ Round-trip latency measured by the Clap Latency Test affects the delay you perceive between asking a question and hearing Claude begin its response. Latency below 60ms keeps the browser-side audio stack out of the critical path; at that level, network and server processing time dominate the perceived delay. Building on this, if the Echo Loopback test reveals significant distortion in the playback, investigate whether your monitoring setup is creating acoustic feedback into the microphone during Claude's audio output.

Claude's turn-taking depends on detecting a sufficient drop in audio amplitude after you finish speaking, which signals that the model should begin generating its response. When browser-side latency is high, the silence detection window at the server receives your audio delayed by the full round-trip time, which means the model waits longer than necessary before responding and the conversation develops an unnatural rhythm where each turn begins with a perceptible pause. Keeping the Clap Latency Test result in the Good range or better minimizes this browser-side contribution and lets the server-side silence detection operate on the most current audio available.

Clipped plosives and transcription errors

Clipping produces harmonic distortion that extends across the entire spectrum above the clipped frequency.² For Claude's speech recognition pipeline, clipping during peak speech levels, particularly during plosive consonants like p and b, corrupts the short audio frames the acoustic model processes. The Clipping Detector triggers when more than 1% of samples in a frame hit 0 dBFS. Even brief episodes at this level during normal speech indicate gain staging that is too high. The Frequency Response display helps confirm that the gain setting that eliminates clipping still delivers sufficient energy through the 200 Hz–4 kHz fundamental speech range.

The language model stage that follows transcription can often infer the correct word from surrounding context even when the transcript contains minor errors, but the speech recognition stage that produces the initial transcript has no such contextual safety net for individual phonemes. A clipped "p" sound at the start of a word produces a distorted waveform that the acoustic model maps to an entirely wrong phoneme candidate, and the language model downstream receives this wrong phoneme sequence with no way to know the original signal was corrupted by digital saturation rather than being a genuine speech sound. This is why the Clipping Detector matters more for Claude Voice Mode than for text-based interactions.

Gain staging for Claude's speech recognition pipeline

Because Claude's voice pipeline uses a speech recognition stage before the language model processes your input, gain staging affects transcript accuracy directly rather than indirectly through a processing buffer. Starting at 60% OS input gain provides enough signal for a usable Noise Floor Grade in most quiet rooms while leaving headroom below the Clipping Detector threshold for a typical voice. Run the Noise Floor Grade first; if the result is Noisy, increase gain by 5% and repeat. If the result is Good or Excellent, run the Clipping Detector while speaking at maximum normal volume before beginning any session.

Finding the optimal gain bracket in under five steps

The search for the optimal gain setting takes five adjustment steps at most in a typical room. Start at 40% OS input gain, run the Noise Floor Grade, and note the result. Increase to 50% and repeat. At each step, the grade improves until room noise becomes the dominant source and further gain increases stop improving it. That inflection point is the optimal gain setting. Confirm by running the Clipping Detector at that gain; if no badge appears during loud speech, the setting is both noise-floor-optimal and clipping-safe.

Confirming the safe window before each session

After finding the gain level where the Noise Floor Grade is Good and the Clipping Detector shows no badge during loud speech, document the OS gain slider position with a screenshot. Revisit this calibration when you change rooms, change hardware, or reconnect the microphone after a period of non-use. Gain staging that was optimal in a previous session may be too high if the OS default communications device changed and selected a different microphone at its default gain setting. The two-minute dual-test sequence prevents this common source of degraded voice sessions.

The dual-test sequence is the Noise Floor Grade followed immediately by the Clipping Detector at the same gain, completed in under two minutes. Keeping the screenshot of the OS slider beside the microphone means you can restore the exact position after any device change without re-running the full search, which is the practical value of documenting the calibration rather than relying on memory of a percentage.

Understanding how soft speech affects clipping risk

Clipping risk in Claude Voice Mode is determined by your loudest typical speech, not your average or softest speech. The Clipping Detector threshold of 1% samples at 0 dBFS means it fires when any speech peak exceeds the digital ceiling, regardless of how quiet the rest of the recording is. If your gain staging is calibrated to your whispered or quiet voice, the gain may be set too high to handle emphatic speech, technical explanations delivered with more force, or the natural loudness increase that occurs when speaking about something important.

Calibrating with loud consonants as the test signal

During the Clipping Detector calibration run, include deliberate emphatic speech rather than only conversational-volume speech, then set the Claude voice gain headroom once the badge clears. Deliver a sentence at the volume you would use when making a strong point, not at the level of polite background conversation. Also include deliberate plosive consonants: phrases like "pepperoni pizza" and "completely correct" generate the peak transients that most commonly trigger the detector. If the badge appears during this calibration run, reduce gain and repeat.

Setting a headroom buffer below the clipping ceiling

Once you confirm the ceiling gain level (highest gain where the badge does not appear during loudest speech), set your working gain 3–5 dB below that ceiling. Excited speech, unexpected questions that prompt a louder response, or the natural emphasis of explaining something technical all produce transients above your calibration baseline. The headroom buffer absorbs these excursions without triggering clipping. A 3 dB buffer is the minimum; 5 dB is recommended for conversational AI sessions where tone and volume vary unpredictably throughout the exchange.

When to use this

Check your microphone before any Claude Voice Mode session, particularly when switching between different input devices, audio setups, or environments. A 60-second pre-session check prevents transcription errors that slow the conversation.

Examples

Clipping badge appears during normal speech — Claude transcribes consonants incorrectly

Gain reduced 8 dB: no clipping badge, Noise Floor Grade Excellent — accurate transcription

Noise floor −35 dBFS (Very Noisy) — multiple transcription errors per sentence

Switched to USB cardioid microphone: −58 dBFS — sentence-level accuracy restored

Gemini Live Mic Test

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.

Gemini Live gain control in a noisy room

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.

Interrupting Gemini Live while it answers

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 that happens before Gemini hears you

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

Microsoft Copilot Voice Mic Test

On Windows, Microsoft Copilot Voice operates through the Windows audio stack by design, not as a workaround but as an intentional integration. Every audio enhancement in the Windows system applies before Copilot Voice processes input: Noise Suppression, Acoustic Echo Cancellation, and Automatic Gain Control in the Windows audio device properties panel all modify the signal before Copilot Voice receives it¹. Consequently, the Noise Floor Grade and Clipping Detector in this browser-based tool measure the post-enhancement signal that Copilot Voice actually sees.

Gain staging set in the Windows sound control panel is the primary dial for the Noise Floor Grade and Clipping Detector results. The Windows microphone level slider controls input amplification at the OS level, and this applies before any application-specific processing. Because both Copilot Voice and this testing tool read from the same OS audio stream, calibrating your Windows microphone gain with the Noise Floor Grade test directly calibrates the input level that Copilot Voice receives². The Clap Latency Test result reflects the Windows audio buffer settings, which are configurable via audio device properties.

Windows noise suppression and the measured floor

Windows Noise Suppression, when enabled, can dramatically reduce the measured noise floor, sometimes from Noisy (−40 dBFS) to Excellent (−60 dBFS). Yet this apparent improvement may disguise rather than solve an underlying problem: Windows classes noise suppression and automatic gain control as adaptive processing that its raw capture mode must leave out, so a reading taken with them on describes the processed signal rather than the microphone itself³.

Hardware baseline versus enhanced measurement

Run the Noise Floor Grade with Windows enhancements disabled first to get the hardware baseline, then compare with enhancements enabled. Copilot Voice performs best when the hardware input is already clean rather than relying on suppression processing. The difference between the two readings reveals how much Windows audio processing is contributing to your noise floor result. If the hardware baseline is already Good or Excellent, Windows enhancements are unnecessary and may introduce processing artifacts that degrade voice quality. If the hardware baseline is Noisy, enhancements can help, but physical room treatment produces a cleaner result without the warbling or metallic side effects that suppression algorithms sometimes introduce.

Windows audio buffers and Copilot response delay

Windows audio buffer settings determine the primary source of browser-side audio latency in this test. Larger audio buffers reduce CPU interrupts at the cost of higher latency. The Clap Latency Test shows the total round-trip, which includes Windows audio processing, the browser's WebAudio implementation, and network overhead. For Copilot Voice specifically, keeping latency below 80ms ensures the conversation turn-taking feels responsive. Building on this, Windows Exclusive Mode in audio device advanced settings allows applications to bypass the shared audio session and access the hardware directly, reducing latency by 20 to 40ms in some configurations⁴.

How Windows audio buffers stack across the pipeline

The total round-trip latency measured by the Clap Latency Test is the sum of multiple independent buffer stages: the Windows audio driver buffer, the Windows mixer buffer if shared mode is active, and the browser's WebAudio internal buffer. Each stage adds its own delay independently, so a system with three 10ms buffers produces 30ms of audio delay before the signal even reaches the network stack. Understanding this stacking behavior helps you prioritize which buffer to shrink first when the Clap Latency Test returns a result above the Good threshold.

Windows echo cancellation and clipped speech

Windows Acoustic Echo Cancellation, when active, processes both the microphone input and speaker output simultaneously. This helps prevent speaker audio from feeding back into the microphone, which matters for the Echo Loopback test. However, echo cancellation applies a nonlinear processing stage that can significantly alter the Frequency Response display in ways that do not reflect your microphone's actual hardware characteristics, because the algorithm continuously models and subtracts the estimated speaker contribution from the microphone signal⁵.

Consequently, the Frequency Response reading on Windows with echo cancellation enabled may not represent your microphone's hardware response accurately; it reflects the post-processing output, which is also what Copilot Voice receives. This distinction matters when diagnosing audio quality problems: if the Frequency Response display looks uneven or shows unexpected rolloff with enhancements enabled, the issue may be in the Windows processing layer rather than the microphone hardware. Disable all enhancements and compare the display again. If the response smooths out, Windows processing was the cause, and you can selectively re-enable individual enhancements to identify which one introduces the artifact.

Diagnosing Windows audio enhancement conflicts

In Windows audio device settings, four common enhancements can affect the Noise Floor Grade in opposite directions: Noise Suppression typically improves it, Automatic Gain Control destabilizes it across runs, and Bass Boost raises the low-frequency noise contribution. Acoustic Echo Cancellation has minimal effect on a measurement taken in silence. Disable all enhancements first and run the Noise Floor Grade for a clean hardware baseline. If the baseline is Good or Excellent, enhancements are unnecessary for your environment. If the baseline is Noisy, re-enable Noise Suppression only and run the test again to see whether that single enhancement produces enough improvement to bring the grade into the Good range without introducing processing artifacts.

If Noise Suppression alone improves the grade by 5 or more dBFS without introducing audible artifacts in the Echo Loopback playback, keep it enabled. If Noise Suppression improves the grade but creates warbling or metallic quality in the Echo Loopback, disable it; the hardware noise floor is too high for clean suppression processing, and physical environment improvement is required instead. Automatic Gain Control changes the Noise Floor Grade result unpredictably across runs because it adjusts gain dynamically⁶; always disable AGC before running the Noise Floor Grade to get a stable and repeatable measurement.

Re-enabling all four enhancements simultaneously after a Noisy baseline makes it impossible to identify which specific processing stage is responsible for the improvement or for any new artifacts that appear. By enabling one enhancement at a time and running the Noise Floor Grade after each change, you build a clear picture of what each stage contributes: Noise Suppression might improve the grade by 8 dBFS while adding slight warbling, while Bass Boost might worsen it by 3 dBFS with no audible benefit. This systematic single-variable approach takes slightly longer than testing all combinations but produces a definitive answer about which enhancements are genuinely helping your specific microphone and room combination.

Enabling Exclusive Mode to reduce Copilot Voice latency

Exclusive Mode in Windows audio device settings allows a single application to take direct control of the audio hardware, bypassing the shared audio mixer and reducing buffering by 15–40ms in most configurations. Copilot Voice on Windows benefits from this: the shared audio session adds processing stages that accumulate latency. Enabling Exclusive Mode requires that no other application is simultaneously using the microphone; only one application can hold exclusive access at a time, so the improvement applies only when no other audio application has opened the device.

In Windows Sound Control Panel, right-click your microphone, select Properties, and navigate to the Advanced tab. Check both "Allow applications to take exclusive control of this device" and "Give exclusive mode applications priority." Close the dialog, then run the Clap Latency Test and compare the result against your baseline. A reduction of 15–40ms confirms Exclusive Mode is active and effective for your setup. If the Clap Latency Test shows no improvement, another buffer stage in the pipeline is the dominant contributor to latency rather than the shared audio session overhead.

When Exclusive Mode conflicts with other applications

Exclusive Mode creates a compatibility constraint: any application that tries to open the microphone while Copilot Voice holds exclusive access will fail silently or fall back to a lower-quality shared mode. Browser-based tools including this mic test page cannot open the device while an exclusive application holds it. Close Copilot Voice before running any diagnostic test here, then re-open it after confirming your baseline. This sequence ensures both the test and Copilot Voice access the microphone at its configured sample rate and bit depth rather than through a resampled shared session.

Treat the close-and-reopen step as mandatory rather than optional, because a shared session that resamples the device to a different rate than the microphone native rate adds both latency and a slight quality loss that the test would otherwise attribute to the hardware. Keeping Copilot Voice closed while you confirm Copilot Voice Exclusive Mode latency guarantees the Clap Latency Test and Noise Floor Grade reflect the true raw device rather than a software-mediated stream.

When to use this

Use this check before any Copilot Voice session on Windows, particularly after updating Windows audio drivers, changing microphone devices, or modifying Windows audio enhancement settings.

Examples

Noise Floor Grade reads Excellent but speech sounds warbling — suppression artifacts in processed signal

Disabled noise suppression: hardware noise floor −55 dBFS (Good) — natural voice quality without artifacts

Clap Latency Test: 85ms — slightly above Good threshold

Enabled Exclusive Mode via advanced properties: 48ms — Good grade

OpenAI Whisper Mic Test

For transcription work, OpenAI Whisper is a speech recognition model available via API that accepts audio file uploads for batch transcription. Unlike real-time voice AI services, Whisper processes audio after the fact rather than in a continuous stream. This distinction matters for which tests apply: latency is irrelevant to batch transcription, but noise floor accuracy directly predicts how many corrections you will need to make to Whisper's output.

OpenAI trained Whisper on 680,000 hours of web audio and reports that the scale of that data improved its robustness to accents, background noise and technical language¹. Yet the noise floor remains the strongest single predictor of transcription accuracy even for Whisper: a Noise Floor Grade of Good or Excellent produces noticeably cleaner transcripts than Noisy grades, particularly for proper nouns, technical terminology, and speech with moderate accents. The Clipping Detector and Frequency Response display are secondary checks that confirm gain staging is appropriate before recording begins.

Noise across the frequency bins Whisper reads

Whisper's architecture pre-processes audio using log-Mel spectrogram features across 80 frequency bins from 0 to 8 kHz². Noise that concentrates in specific bins, like HVAC rumble below 200 Hz and fan noise in the 100–400 Hz range, competes directly with the fundamental frequency range of human voice. Furthermore, Whisper processes audio in 30-second chunks. Background noise that fluctuates within those chunks can affect word boundary detection at the chunk boundaries, producing occasionally garbled words at those points.

Consistent noise across recording chunks

A Noise Floor Grade of Good or Excellent indicates consistent noise conditions throughout the recording session. Whisper processes audio in fixed 30-second segments, and the model performs best when the noise floor remains stable across those segment boundaries. If the noise level shifts dramatically mid-recording, for example when an HVAC system cycles on between segments, the model may produce different transcription quality at the boundary point compared to the surrounding audio. Running the Noise Floor Grade at the start, middle, and end of a long recording session confirms whether your room conditions remain stable throughout.

Plan long recordings around the stable reading windows the test reveals, because a chunk that straddles an HVAC cycle or traffic burst is exactly where Whisper tends to garble a word at the segment edge. Catching the instability with three readings before you press record is far cheaper than re-transcribing a compromised segment afterward, and it tells you which part of the day to avoid for critical recordings.

When latency matters for Whisper

Latency is not a factor in Whisper API batch transcription: you record first, then upload. However, if you use Whisper in a real-time pipeline (local deployment or third-party wrappers that process audio in near real-time), the Clap Latency Test becomes relevant. At high latency, real-time wrappers fall behind the audio stream and accumulate delay.

Batch use versus real-time wrappers

For pure API batch use, skip the Clap Latency Test and focus on the Noise Floor Grade and Clipping Detector before each recording session. Real-time wrappers that stream audio to a local Whisper model still depend on noise floor quality, but they add latency as a secondary concern because the model must keep pace with the incoming audio stream. If you deploy a local Whisper instance for live transcription, run both the Noise Floor Grade and the Clap Latency Test: the noise floor predicts accuracy while the latency prediction tells you how quickly the transcription will appear after each spoken phrase.

Choosing between API batch and local deployment for time-sensitive work

When transcription speed matters more than convenience, a local Whisper deployment eliminates the upload step entirely and processes audio on your own hardware, but this shifts the performance bottleneck from network latency to your CPU or GPU's inference speed. A local large-v3 model on a modern GPU transcribes in near real-time with acceptable latency, while the API introduces upload and queue delays that add seconds to minutes depending on file length and server load. CapyToolkit's pre-recording checks apply equally to both deployment paths: clean audio at the source matters more than which Whisper variant processes it.

Why clipping hurts Whisper more than noise

Clipping is more damaging to Whisper transcription than noise, because distorted waveforms create false spectral energy across multiple Mel filter banks simultaneously³. This scatters recognition confidence across multiple phoneme candidates at once, producing substitution errors rather than insertion or deletion errors: the transcribed word sounds wrong rather than being absent. The Clipping Detector confirms that your recording gain is below the saturation threshold before you begin. The Frequency Response display is useful for confirming that the microphone covers the 80 Hz–8 kHz range that Whisper's spectrogram processing uses most heavily, because a microphone that rolls off well below 8 kHz will capture the full speech spectrum while one that drops off at 3.4 kHz (the upper limit of narrowband telephone audio⁴) will lose critical consonant information and produce noticeably worse transcription accuracy even if the noise floor reading appears acceptable.

Setting up your recording environment for Whisper accuracy

Setting up your recording environment before a Whisper session is a one-time calibration that pays off across every recording you do in that space. Start with the Noise Floor Grade: run it three times and note the average. A consistent result within 2–3 dBFS across runs means the room is stable. Variation of 5 dBFS or more indicates an intermittent noise source (HVAC cycling, a refrigerator compressor, or traffic bursts) that will appear as noise spikes in the recording and affect word boundary detection at the 30-second chunk boundaries Whisper processes.

Assessing run-to-run variation before committing to a session

Run-to-run variation above 5 dBFS means the intermittent noise source is significant enough to create gaps in a long recording. Track which minutes of the day show stable readings and which show variation. HVAC systems typically cycle every 10–15 minutes; if your stable readings cluster in a consistent window, schedule recordings during that window rather than treating the noise floor as fixed. Three stable consecutive readings within 2 dBFS of each other confirm the room is ready.

Testing gain ceiling before a long recording session

Before any recording session intended for Whisper, run the Clipping Detector for 20 seconds while speaking at your loudest normal voice plus deliberate consonant sounds. The goal is to confirm the badge never appears during that window. If it does, reduce gain by 3 dB and repeat. Clipping discovered mid-recording means the affected segments require re-recording or produce transcript errors that are time-consuming to correct. Confirming the ceiling before starting takes under two minutes and guarantees a clean recording throughout the session.

File format and sample rate for Whisper transcription

Before recording for Whisper API upload, confirm your microphone's sample rate output in OS audio settings. Whisper internally resamples all audio to 16 kHz for its mel-spectrogram feature extraction, which means recording at 48 kHz provides no accuracy benefit beyond what 16 kHz captures. The Frequency Response display confirms whether your microphone covers the 80 Hz–8 kHz range meaningfully: a display that shows consistent energy through 8 kHz with a drop above means the signal is complete at the range Whisper uses most heavily.

File format affects the 25 MB API upload limit more than audio quality⁵. A 30-minute interview recorded as 48 kHz 16-bit WAV is approximately 165 MB, well above the limit. Recording as 16 kHz 16-bit WAV reduces the size to around 55 MB, still over the limit for long sessions. Recording in a compressed format such as opus or mp3 at 64 kbps reduces 30 minutes to under 15 MB while preserving accuracy, since Whisper's training included compressed audio formats at these bitrates. Before the session, pick the right Whisper audio format to prevent upload failures that require re-recording or manual file splitting.

When to use this

Run this check before any extended recording session you plan to transcribe with Whisper. Interviews, lectures, podcasts, and meeting recordings all benefit from a verified noise floor before you start. A clean input means less time correcting output.

Examples

Noise floor −42 dBFS (Noisy) — proper nouns and technical terms misrecognized, 15% error rate

Moved to quieter office: noise floor −58 dBFS — error rate drops below 3%

Clipping badge appears during louder speech — Whisper produces artifact errors at high-energy segments

Input gain reduced 10 dB, no clipping badge — Whisper accuracy improves across the full episode

Amazon Alexa Mic Test

On single-microphone setups, Amazon Alexa's far-field design needs extra care: the Amazon Echo uses a seven-microphone circular array with beamforming, noise reduction and echo cancellation to pick up wake words across a room¹. When you use Alexa through a web browser or application with a single cardioid microphone, the expected far-field behavior translates into near-field signal processing that behaves differently. Specifically, noise floor thresholds calibrated for beamforming arrays are applied to single-microphone input, which means near-mic use requires a lower noise floor than far-field expectations suggest.

Wake-word detection is the most noise-sensitive stage in Alexa's pipeline². The keyword model that listens for "Alexa" is trained to detect a specific acoustic pattern against a background noise model. When your measured noise floor approaches −40 dBFS, false wake-word triggers increase and genuine wake words become less reliable. Furthermore, the Clap Latency Test reveals the latency that affects how quickly Alexa's command processing feels after the wake word is detected.

Wake-word false triggers and room noise

Alexa's wake-word detection uses an always-listening keyword model that runs independently of the main speech recognition pipeline. This model has its own noise floor sensitivity curve: false activations increase significantly when ambient noise reaches the −40 dBFS range (Noisy on the Noise Floor Grade)³. Furthermore, genuine wake-word activations become unreliable above −45 dBFS because the detection confidence threshold requires a certain speech-to-noise ratio to trigger.

Practical minimum for single-mic wake words

A Noise Floor Grade of Good (below −50 dBFS) is the practical minimum for reliable single-microphone wake-word detection. Echo devices compensate for noisier environments using microphone array beamforming that a single cardioid cannot replicate. Without that array processing, the single microphone needs a cleaner signal to achieve the same wake-word confidence. If your Noise Floor Grade is in the Noisy range, the wake-word model may fail to detect your voice from more than one meter away, or it may trigger falsely on background sounds that briefly resemble the Alexa phoneme pattern.

Command response delay and speaker coupling

After wake-word detection, Alexa transitions to command processing mode. Round-trip latency measured by the Clap Latency Test contributes to the perceived delay between the end of your command and Alexa's response. Unlike conversational AI services, Alexa's responses are typically brief and discrete, so latency above 100ms does not degrade the experience as severely. Nevertheless, keeping the Clap Latency Test result in the Good range ensures that your command reaches Amazon's servers with minimal browser-side delay. This matters more for multi-step interactions where you issue several commands in quick succession and need each one to register before the next begins processing.

Echo Loopback for wake-word coupling

Building on this, the Echo Loopback test is particularly useful for Alexa: playing Alexa's audio response through speakers near the microphone creates acoustic feedback that can trigger false wake words. The Loopback test reveals how much of the speaker output your microphone is capturing. If the recorded level during Alexa playback exceeds −45 dBFS relative to your voice level, the acoustic coupling between speaker and microphone is strong enough to cause false activations during normal use. Repositioning the microphone to maximize the cardioid's rear rejection toward the speaker, or switching to headphones for Alexa monitoring, eliminates this coupling entirely.

Clipping in the band the Alexa wake word uses

Alexa's wake-word model is optimized for the 100 Hz–4 kHz range where the "Alexa" phoneme pattern lives⁴. Clipping during command words creates distortion that spreads across this band, degrading phoneme matching. The Frequency Response display helps confirm that your microphone covers the 100 Hz–4 kHz band consistently; a significant dip in the 1–3 kHz region will affect wake-word detection reliability. For browser-based Alexa use, the command is typically one to three words, making clipping on any single command word more consequential than in longer conversational speech.

Because the wake-word model evaluates the entire command in one brief analysis window, a clipped phoneme at the start of the command can corrupt the model's confidence score for the entire phrase, causing Alexa to either misinterpret the command or fail to respond at all. Running the Clipping Detector while speaking a few test commands at your normal volume before relying on Alexa for important tasks ensures that the gain staging you have set preserves the full phoneme pattern the wake-word model needs.

Near-field microphone positioning for single-mic Alexa use

Near-field positioning for single-mic Alexa use differs substantially from the far-field assumptions the Echo device's array is designed for. An Echo placed on a shelf captures your voice from 1–3 meters using beamforming that rejects ambient noise. A single cardioid microphone on a desk functions best at 15–30 cm, where the direct voice signal dominates over room noise without pushing the Clipping Detector during normal command volume. Moving further away forces higher gain, which raises the measured noise floor and degrades wake-word reliability at the same time.

The cardioid pattern rejects sound from the rear null point by 15–20 dB relative to on-axis sensitivity⁵. Position the microphone so that the rear of the capsule faces the Echo speaker, rather than placing the capsule between you and the speaker. This reduces the speaker's playback from entering the Noise Floor Grade measurement and lowers the risk of Alexa's own voice triggering false wake-word detection. The Frequency Response display confirms whether speaker audio is still coupling into the microphone after repositioning: if the display shows energy during Alexa's response that was absent during silence, coupling is still present and further adjustment is needed.

Testing Alexa playback as a noise source with the Echo Loopback

Alexa's synthesized voice output, played through a nearby speaker, contributes to your microphone's noise floor measurement and can trigger false wake-word detections during playback. The Echo Loopback test captures this accurately: run the test while Alexa is speaking its response to a command. The playback recording reveals exactly how much of Alexa's voice the microphone captures. If the recorded level during Alexa's playback exceeds −50 dBFS relative to the signal level during your commands, the coupling between speaker and microphone is strong enough to trigger false activations.

Repositioning versus headphones to eliminate acoustic coupling

Reducing speaker volume lowers the coupling level proportionally but may reduce playback intelligibility. Repositioning the microphone to maximize the cardioid's rejection null toward the speaker is more effective. Switching to headphones for Alexa monitoring eliminates the speaker-to-microphone coupling entirely and produces the cleanest Noise Floor Grade result. The Echo Loopback test is the most direct way to quantify how much coupling exists before and after a repositioning change: run the test during an Alexa response, note the captured level, reposition, and run the test again to confirm the improvement numerically.

To quantify Alexa voice coupling in the loopback before relying on wake words, use headphones when repositioning is not practical, because they remove the speaker entirely from the microphone's acoustic environment rather than merely reducing its level. If you cannot use headphones, aim for the −50 dBFS captured-level threshold as the cutoff where false triggers become likely, and treat any reading above it as a signal to move the microphone further from the Echo speaker or angle the rear null toward it.

When to use this

Use this check when setting up Alexa web or app access for the first time, or when Alexa frequently fails to wake or misunderstands commands in your current environment.

Examples

Noise floor −38 dBFS — Alexa triggers on colleague conversations, misses some genuine wake words

External USB cardioid microphone: −60 dBFS — reliable wake detection, no false triggers

Echo Loopback shows Alexa's voice response bleeding back into the mic — false wake-word triggers during playback

Moved mic away from speaker, angled cardioid to reject speaker: echo feedback eliminated

Apple Siri Mic Test

With Apple Silicon, Siri and macOS Dictation both use on-device speech recognition models, processing audio locally without a server round-trip for supported queries¹. On-device processing has a distinct noise floor characteristic: the recognition model running at inference time on the Neural Engine processes audio in real time without the error-correction passes possible in batch transcription systems². This makes the on-device model sensitive to clipping in a specific way: a single clipped frame at the wrong moment corrupts a phoneme that the real-time decoder cannot recover from by looking at subsequent context.

Apple's voice-processing audio unit includes automatic gain control for the processed microphone signal³. Gain control normalizes amplitude variation rather than removing background noise, so it does not lower the noise floor. Consequently, the Noise Floor Grade reflects the true hardware noise floor even with OS gain control active, while the Clipping Detector may show cleaner results than the hardware gain setting implies, because gain control is pulling the level down before peaks reach 0 dBFS.

Hey Siri on a single desk microphone

Siri and macOS Dictation use always-on listening for "Hey Siri" when enabled, with the same far-field detection limitations as Alexa in browser contexts: a single cardioid microphone requires a lower noise floor than Apple assumes for the microphone array in an iPhone. A Noise Floor Grade of Good or Excellent (below −50 dBFS) is the threshold for reliable detection. Furthermore, macOS Dictation's continuous mode (where speech is transcribed as you speak) shows more sensitivity to noise floor than command-based Siri, because each word must be resolved without a natural pause that aids segmentation.

Run CapyToolkit's Noise Floor Grade before extended dictation, because the continuous mode needs a cleaner floor than short Siri commands. In command mode, Siri processes a brief 2 to 5 word phrase with a constrained vocabulary that the acoustic model can resolve even with moderate background noise. Continuous Dictation, by contrast, transcribes unlimited vocabulary in a real-time stream where every word must be resolved without the benefit of command-boundary context. The practical difference is approximately 5 to 10 dBFS: a Noise Floor Grade of Good may suffice for Siri commands, but continuous Dictation benefits from Excellent grades to maintain accuracy across long passages.

On-device processing and browser latency on macOS

Siri on macOS performs voice processing locally for many commands, which eliminates the server-side network latency that affects cloud-based AI services⁴. The Clap Latency Test therefore measures only browser-to-OS audio path latency for browser-based access scenarios. For dictation in native macOS applications, latency depends on Apple's Core Audio stack rather than the WebAudio path measured here.

Browser latency versus native dictation latency

If the Clap Latency Test shows high values in Chrome on macOS, Safari typically shows lower latency on Apple hardware because it uses Core Audio APIs more directly. The browser audio sandbox that Chrome applies adds processing stages that increase round-trip delay compared to Safari's more direct path to the audio hardware. For the lowest latency browser-based audio testing on macOS, Safari is the better choice. However, native macOS dictation bypasses the browser audio stack entirely and uses Core Audio directly, which means the latency you experience during actual Dictation use will be lower than what the Clap Latency Test in any browser reports.

Clipping and the 16 kHz speech model

Apple's Neural Engine based speech recognition processes audio at 16 kHz sample rate, focusing model capacity on the 80 Hz to 8 kHz range⁵. OS gain control partially masks gain overload by lowering the level before it reaches the digital ceiling, but if input gain is so high that even the reduced peak exceeds 0 dBFS, the Clipping Detector will flag it. Furthermore, the Frequency Response display is useful for confirming that your microphone's response through 80 Hz to 8 kHz is consistent, because the on-device model is not designed to compensate for severe frequency response gaps in the input.

Why OS gain control does not replace proper gain staging

macOS gain control operates on the digital audio stream after the ADC has already captured and quantized the signal, which means it can reduce peak amplitudes but cannot recover headroom that was lost during the analog-to-digital conversion stage. If your input gain drives the ADC into saturation before gain control even receives the samples, it simply reduces the amplitude of already-clipped digital values without restoring the original waveform shape. Setting the input gain low enough that gain control rarely has to step in preserves the full dynamic range that the on-device model needs for accurate phoneme discrimination.

Run the Clipping Detector before relying on Dictation for important text, because a clean reading after gain control is not proof the gain is correct: it only means the processed output stayed under the ceiling, while the underlying signal may already be saturated and distorted at the conversion stage. A clean detector reading combined with a Noise Floor Grade in the Excellent range confirms the input chain is healthy end to end rather than merely flattened by the OS processor.

macOS Dictation versus Siri: different noise floor requirements

Between macOS Dictation's continuous transcription mode and Siri's discrete command processing, the noise floor requirement differs by approximately 5 to 10 dBFS. Siri processes short commands, typically 2 to 5 words, and has a brief, defined recognition window for each interaction. The acoustic model can use surrounding context to resolve a word partially obscured by noise because the command vocabulary is constrained. A Noise Floor Grade of Good (below −50 dBFS) is sufficient for reliable Siri command recognition with common vocabulary in a moderately quiet room.

Why continuous Dictation requires a higher grade than Siri commands

Continuous Dictation mode transcribes speech in a stream without natural command boundaries. The acoustic model encounters longer, less predictable vocabulary including proper nouns, technical terms, and complex sentence structures. Every word must be resolved on its own merits without the contextual disambiguation that short command recognition relies on. For Dictation accuracy that approaches what you would expect from an accurate typist, a Noise Floor Grade in the Excellent range (below −60 dBFS) is the practical target. Background noise in the Noisy range produces Dictation accuracy that requires frequent manual correction, negating the time benefit Dictation is supposed to provide.

Setting the correct input device in macOS Audio MIDI Setup

macOS routes microphone audio through the System Settings > Sound > Input panel, but the Audio MIDI Setup application provides more granular control over which device is selected and at what sample rate. When multiple microphones are connected, the default input in System Settings controls what most applications use. Siri and Dictation respect the default input device unless a specific application overrides it. Verifying that the Noise Floor Grade test and Siri are using the same microphone requires checking System Settings > Sound > Input and confirming your preferred device is selected before testing.

If the Noise Floor Grade returns an Excellent result but Siri accuracy remains poor, the two tools may be using different devices. Some third-party applications set themselves as the default input and do not release it properly after closing. Check System Settings > Sound > Input after closing all other applications to confirm the correct device is active. Running the Noise Floor Grade immediately before asking Siri a question lets you see which mic Siri actually uses and confirms both are operating on the same audio path within the same OS session, making the pre-session check a reliable calibration step rather than a theoretical one.

When to use this

Run this check before using Siri voice activation or macOS Dictation with an external microphone, especially when switching between the built-in microphone and an external USB or Bluetooth device on macOS.

Examples

OS gain control masking clipping — Dictation still produces errors on plosive sounds (p, b, t, k)

Reduced OS gain by 15 dB, gain control no longer working hard: accurate Dictation across all consonants

Clap Latency Test: 110ms (High) — Siri command recognition feels delayed

Switched to USB wired microphone: 35ms — Siri responds instantly