Microphone Not Working: Find the Layer, Then Fix It

Microphone Not Working: Find the Layer, Then Fix It

A microphone that "does not work" usually works fine. Something between the capsule and the app is blocking it, and that something sits in one of three layers: the hardware and its driver, the operating system's privacy permission, or the app's own device choice and permission. Each layer has a different fix, so changing app settings while the OS is blocking access wastes your time, and reinstalling drivers while the app has simply picked the wrong device does too.

Start with one browser test, because it answers the layer question in a few seconds. If your browser can read the microphone, the hardware, driver and OS permission are all working, and the fault lives in the app. If the browser cannot read it, no app setting will help until you fix the layer underneath. The sections below cover the app or system where your microphone fails, starting with Zoom.

Check the hardware before you change app settings

Run the Noise Floor Grade first. Your browser asks for the microphone through getUserMedia(), which only returns a live stream after you accept the permission prompt and rejects with NotAllowedError when access is blocked.¹ A grade of any kind, even Very Noisy, proves four things at once: the capsule produces a signal, the cable or internal connection is intact, the OS driver delivers audio, and the OS lets a desktop app use the microphone. Then speak at your normal volume with the Clipping Detector open. Movement on the waveform confirms the level is high enough for an app to detect your voice.

Reading a failed test

The error tells you which layer to fix. A permission error points at the OS privacy settings or the browser's site permission. A "device not found" error points at a hardware mute switch, a disabled device or a driver problem. A grade that reads suspiciously low and never moves when you clap usually means digital silence: something below the browser is handing it an empty stream, which Android's microphone toggle and some device policies do on purpose.

Run the test in two browsers before you change any setting, because that one comparison separates a browser problem from a system one. A microphone that fails in Chrome and works in Firefox has a per-site permission or profile problem rather than a driver fault, and a microphone that fails in both is blocked somewhere the browsers share: the OS privacy list, a physical switch, or the device itself.

Why a working browser test clears the hardware

Every desktop app reads the microphone through the same OS audio stack the browser uses. Once the browser test works, a call app that still hears nothing has the wrong device selected, lacks its own permission, or is processing your audio badly. Keep one difference in mind: your browser may apply its own echo cancellation and noise suppression by default, while each call app runs its own processing on top, so quality problems can still differ between the two even when access works in both.²

Microphone Not Working on Zoom

Zoom's audio device selection overrides the OS default¹. The operating system's default microphone does not automatically become Zoom's active microphone. Zoom remembers the last device it used, which can become outdated when microphones are changed or disconnected. A browser-based test confirms the hardware is working at the OS level before investigating Zoom's internal device management.

Zoom's audio settings also include built-in gain control, echo suppression, and noise suppression that run on the audio stream after Zoom captures it². These processing stages can affect perceived quality independently of the hardware. By testing the microphone here first, where none of Zoom's processing is applied, you establish a clean hardware baseline before deciding whether Zoom's processing is the source of any quality issues.

Confirm the microphone works before you open Zoom

Run the Noise Floor Grade. getUserMedia() resolves to a MediaStream only once the permission prompt is accepted, and rejects with NotAllowedError when it is declined.³ A result confirms the microphone is active at the OS level and accessible to applications. The Clipping Detector, run while you speak at normal volume, confirms gain staging is correct before introducing Zoom's gain control into the signal chain.

Interpreting the result before opening Zoom

If either test fails here, the problem is at the OS level. Fix it here before opening Zoom. Zoom cannot bypass OS-level permission denials or driver failures, so resolving the issue at the browser level guarantees it will also be resolved in Zoom. If the Noise Floor Grade returns a result but the Clipping Detector shows no activity when you speak, the microphone is connected but the gain may be set too low for Zoom to detect input above its internal threshold. Running both tests in sequence before opening Zoom eliminates the most common OS-level causes in under 30 seconds and prevents the frustrating experience of joining a Zoom call only to discover that the microphone is not sending any signal.

When Zoom picks the wrong device or over-processes

Noise Floor Grade succeeds here: microphone hardware is working at the OS level, which means the problem is in Zoom's own device selection or permission settings rather than in the hardware or driver. Go to Zoom Settings > Audio > Microphone, verify the correct device is selected in the dropdown, and click "Test Mic." If the Zoom level meter shows no input, Zoom has the wrong device selected or the device it selected is no longer connected.

If the level meter moves but quality is poor, Zoom's processing settings (suppress background noise set to Aggressive, echo suppression) may be over-processing the signal and introducing audible artifacts like metallic voice character, choppy speech during quiet syllables, or robotic-sounding compression that makes your voice sound unnatural to other participants on the call.

Why Zoom's device selection overrides the OS default

Zoom remembers the last microphone it used and does not automatically follow the OS default device when you connect new hardware, which means the OS can show your USB microphone as the active default while Zoom continues sending audio from a different device that was selected during a previous session. Opening Zoom Settings > Audio and manually reselecting the correct device resolves this disconnect immediately.

Zoom audio settings to change

Zoom desktop app: Settings (gear icon) > Audio > Microphone dropdown. Verify correct device. "Suppress background noise" set to Auto or Aggressive can over-suppress, making voice sound robotic. Set to Low if you have a clean Noise Floor Grade. "Automatically adjust microphone volume" in Zoom can conflict with hardware gain control. Disable it and set hardware gain manually using the Noise Floor Grade for reference. On Windows, Zoom sometimes loses the microphone when the device is unplugged and reconnected because Windows re-enumerates USB devices with a new device ID, and Zoom continues looking for the old ID that no longer exists⁴. Restart Zoom to refresh its device list and force it to rediscover the reconnected microphone.

Zoom's automatic gain control continuously adjusts the input level based on the incoming signal, which creates a conflict when you have already set the gain manually using the Noise Floor Grade as a reference⁵. The AGC may raise the gain during quiet moments, amplifying background noise, or reduce it during loud speech, compressing the dynamic range that gives your voice natural presence. Disabling this feature and setting gain manually with the Noise Floor Grade produces a more consistent and predictable signal that does not fluctuate during a call.

Zoom audio artifacts after hardware confirms clean

If the Noise Floor Grade shows Good or Excellent results here but participants report poor audio quality in Zoom, the source is almost certainly Zoom's internal audio processing rather than the hardware. Zoom's "Suppress background noise" setting at Aggressive applies a strong noise gate that can cut off the quiet beginnings and ends of words², making speech sound choppy. Its echo cancellation can introduce reverb-like artifacts on close-miked voices where no echo is actually present. Zoom applies these processing stages to every microphone signal regardless of quality, assuming that all inputs need the same treatment regardless of whether the source is a noisy laptop mic in a busy cafe or a treated home studio with a broadcast dynamic.

Identifying Zoom suppression artifacts versus hardware noise

Run the Echo Loopback test to capture how your voice sounds before Zoom processing, then join a Zoom test call and compare what participants hear. If the Echo Loopback sounds clean but Zoom participants describe robotic, choppy, or metallic quality, Zoom's processing is the cause. Go to Zoom Settings > Audio and set "Suppress background noise" to Low. If echo cancellation is enabled, disable it when using headphones. Confirm the pre-Zoom signal is still clean in the Echo Loopback before concluding that further Zoom settings adjustment is needed.

Treat the Echo Loopback as the reference recording for this comparison, because it sits upstream of Zoom and shows what the microphone actually captures before any suppression runs. When that recording is clean but the call sounds robotic, the difference is entirely inside Zoom's processing and the fix is the suppression slider rather than the microphone or the room. Re-running the loopback after each Zoom setting change keeps the before-and-after comparison honest.

Saving your Zoom audio settings across sessions

Zoom stores audio settings globally rather than per-device. Capturing a stream through the Web Audio API also hands you a per-stream handle, MediaStreamAudioSourceNode, which is a far more reliable basis for per-device state than anything Zoom exposes.⁶ If you switch between a USB microphone and a laptop built-in microphone, the noise suppression and echo cancellation settings apply to whichever device is currently active. A setting that works well for the USB microphone may over-process the built-in laptop microphone. Before each session, verify the correct microphone is selected in Zoom Settings > Audio and check that the noise suppression level matches what the Noise Floor Grade indicates that device needs. This per-device awareness is important because Zoom applies the same noise suppression and echo cancellation settings globally, which means a suppression level that cleans up a noisy laptop mic may simultaneously degrade the audio quality of a clean USB microphone connected in a different session.

For setups with multiple microphones, map noise floor to Zoom suppression per mic by running the Noise Floor Grade for each microphone you use regularly and noting the grade alongside the Zoom noise suppression setting that works correctly for each. When Zoom receives audio from a microphone whose grade is Good or Excellent, Low suppression is usually correct. When the grade is Noisy, Auto or moderate suppression provides genuine benefit. This approach prevents the common situation of the wrong suppression level being active for the current hardware, which can make a clean microphone sound worse than a noisy one left at default settings.

When to use this

Use this test when Zoom shows no microphone input, when participants on Zoom calls report audio quality issues, or before a critical Zoom call to verify hardware and gain staging independently of Zoom's processing.

Examples

Noise Floor Grade works fine. Zoom still showing disconnected device in dropdown — stale device list

Restarted Zoom — device list refreshed, USB microphone appeared and selected

Noise Floor Grade Excellent, Echo Loopback sounds clean. Zoom suppression causing artifacts on clean signal

Changed Zoom noise suppression from Aggressive to Low — natural voice quality restored

Microphone Not Working on Microsoft Teams

Microphone problems in Microsoft Teams come from three separate layers: OS microphone permission, Teams application audio device selection, and the hardware itself. Isolating which layer is responsible before adjusting settings saves significant troubleshooting time. A browser-based hardware test like this one confirms that the microphone is physically working at the OS level, independently of Teams entirely.

If the Noise Floor Grade returns any reading here, the microphone hardware and OS driver are both functioning. That tells you immediately that the problem is either Teams' device selection or Teams' microphone permission, not the hardware. Conversely, if the Noise Floor Grade fails here, the microphone problem exists below the Teams layer; it is in the OS audio driver or hardware. Fixing it there will resolve it in Teams automatically.

Rule out the signal path before blaming Teams

Run the Noise Floor Grade test. The browser reaches the microphone through getUserMedia(), which resolves to a MediaStream only once the permission prompt is accepted and rejects with NotAllowedError if the user declines or the page is not a secure context.¹ If you see any result, even a Noisy or Very Noisy grade, the microphone is active and accessible to browser applications at the OS level. This rules out hardware failure, driver malfunction, and OS-level permission denial as causes of your Teams problem. A successful Noise Floor Grade result proves that the microphone capsule is converting sound to electrical signals, that the USB or analog path is intact, that the OS audio driver is processing the stream, and that the browser permission is granted, all in a single three-second test.

Hardware baseline before Teams settings

The Clipping Detector can confirm that audio input is being received by watching for the input level indicator while you speak. If the Clipping Detector shows activity when you talk, the microphone signal is reaching the browser through the OS audio stack. This confirms the entire path from capsule to browser is functional, which means Teams should also be able to access the signal. Any Teams-specific problem at that point is in Teams' own device selection or permission settings, not in the underlying hardware or driver.

Once the Clipping Detector shows movement when you speak, the signal path is confirmed end to end through the browser, which is the same path Teams ultimately reads from. That makes the Noise Floor Grade a clean gate: hardware that produces any reading here is almost never the cause of a Teams-only failure, so your time is better spent in Teams' device menu than swapping cables or reinstalling drivers that are already working.

When Teams shows no microphone

Noise Floor Grade returns a result: microphone is working at the OS level. The Teams problem is in Teams' settings or Teams' own microphone permission. Go to Teams Settings > Devices > Microphone and verify the correct device is selected. Noise Floor Grade fails with "microphone not found": microphone permission is denied at the OS level, affecting both this tool and Teams. On Windows, check Settings > Privacy > Microphone and ensure both browser and Teams have access.

When the Noise Floor Grade works but Teams still shows no microphone

If the browser test succeeds but Teams reports no microphone, the issue is almost certainly that Teams is looking at a different audio device than the one the browser selected. Teams maintains its own device selection independently of the OS default², and it can cache a device ID that no longer exists after a USB microphone is reconnected to a different port. The fix is to open Teams Settings > Devices, manually reselect the microphone from the dropdown, and confirm the input level meter moves when you speak. This single step resolves the majority of "mic works everywhere except Teams" reports.

Teams desktop and Teams web use separate permissions

In Teams desktop app: Settings (gear icon) > Settings > Devices > Microphone. Verify the dropdown shows your intended microphone. In Teams web (browser): the browser's microphone permission for teams.microsoft.com must be granted, separate from the OS permission. Click the padlock icon in the browser address bar and check Microphone. In Windows 11: check that "Let apps access your microphone" is On under Windows Settings > Privacy & Security. Teams desktop and Teams web app use separate permission contexts, and the Teams desktop app uses its own embedded browser runtime that maintains a separate microphone permission from the system-level browser permission governing this testing tool³. Granting microphone access to Chrome or Edge does not automatically grant it to the Teams desktop app, which has its own permission prompt the first time it accesses the microphone.

If you dismissed that prompt or clicked "Block" by accident, the desktop app will never access the microphone until you manually re-enable it in the app's permission settings or reinstall to trigger the prompt again. This is one of the most common causes of "mic works in browser but not in Teams desktop" reports.

After Teams reinstallation, microphone still missing

Reinstalling the Teams application does not clear its device configuration cache on Windows, which means if Teams stored a device selection that is no longer valid, reinstallation preserves that stale selection and the microphone problem persists even after a fresh install. After reinstalling, open Teams Settings and verify the microphone device selection explicitly rather than assuming reinstallation resolved the device issue, because the cached device ID from the previous installation may still be pointing to a disconnected or renamed audio device.

Teams stores its device preferences in a local cache that persists across reinstallations, and Microsoft's own guidance is to clear that cache only as a targeted step for a narrow set of client problems, since the step also deletes the diagnostic logs that support needs.⁴ On Windows, navigate to %AppData%\Microsoft\Teams and delete the contents of the Settings folder. This forces Teams to rediscover all available audio devices on the next launch and present them fresh in the device selection dropdown. Always run the Noise Floor Grade before and after this reset to confirm the hardware is accessible to browser applications: if this tool can access the microphone before the reset, the hardware itself is not the problem. After the cache reset, verify the microphone appears correctly in Teams Settings before testing the audio in an actual call.

A cache reset is faster and less disruptive than a full reinstall because it preserves your Teams login, chat history, and workspace configuration while only clearing the device selection state that may be causing the microphone problem. Try the cache reset first; if Teams still cannot access the microphone after the reset, then proceed to a full reinstall as a last resort. This two-step approach saves the 10 to 15 minutes that a full reinstall and re-login requires while resolving the majority of cached device selection issues.

Preventing Teams audio failures after Windows updates

Windows updates often reset audio enhancement settings and can change the default communications device selection⁵. After a Windows update, rerun the Noise Floor Grade to confirm the microphone is still accessible, then open Teams Settings and verify the device selection matches your intended microphone. This two-step check takes under two minutes and prevents the common situation of joining a call and discovering Teams reverted to the laptop's built-in microphone because the update changed the OS default communications device.

Per-location device configuration in Teams

Teams Personal does not remember separate device selections for different physical locations, so if you move between a home desk with a USB microphone and a conference room with a different audio device, Teams may revert to the OS default each time. Configure the OS default communications device to match your current location's preferred microphone before opening Teams, and verify with the Noise Floor Grade that the correct device is active before joining any meeting.

Creating a Windows audio configuration checklist for Teams

Document your working audio configuration by noting the exact device names and gain levels when everything is working correctly. After a Windows update changes your audio behavior, comparing the current settings against this checklist takes under a minute and immediately reveals which setting the update modified. This proactive documentation approach is faster than troubleshooting from scratch every time an update silently changes a default device, yet reconfirm the Teams mic after a Windows update before trusting the cached selection.

When to use this

Use this test when Teams shows "Microphone not working" or when participants in a Teams call report they cannot hear you, before adjusting any Teams settings or reinstalling software.

Examples

Noise Floor Grade works fine in browser — hardware is OK; Teams reset to wrong default device by Windows update

Changed Teams device settings to correct USB microphone — immediately resolved

Noise Floor Grade: Excellent in Chrome. Teams web blocked by browser permission not granted for teams.microsoft.com

Granted microphone permission via Chrome padlock for teams.microsoft.com — fixed

Microphone Not Working on Google Meet

In Chrome, Google Meet requires microphone permission granted at the browser level for the specific Google Meet domain. Chrome's microphone permission system operates independently from the OS permission¹. Even if your OS allows microphone access, Chrome can have the permission blocked for meet.google.com specifically. A browser-based microphone test confirms hardware function independently of Meet's permission system.

The browser test here and Google Meet both use Chrome's getUserMedia API to access the microphone. If this tool can access the microphone in the same Chrome window, Google Meet should be able to as well, unless permissions for meet.google.com are specifically blocked. Conversely, if this tool cannot access the microphone in Chrome, the problem is at the Chrome or OS level, not in Meet specifically, and fixing it here will fix it in Meet.

Chrome needs two grants before Meet can hear you

Run the Noise Floor Grade. getUserMedia() resolves only when Chrome has both the OS-level grant and the per-site grant for the page's origin; a rejection with NotAllowedError means one of the two is missing.² If it returns a result, Chrome has microphone access and the hardware is functioning. If it fails with a permission error, click the camera or microphone icon in the Chrome address bar and check whether capytoolkit.com has microphone blocked. This initial test establishes whether the problem is at the hardware, OS, or browser-permission layer before you spend time adjusting Meet-specific settings that cannot help if the underlying issue is a blocked site permission or a disconnected cable.

Browser permission before Meet device settings

Both this site and meet.google.com need permission granted in Chrome's site settings independently. Chrome treats each website as a separate permission context³, which means granting microphone access to one site does not automatically extend to another. If the Noise Floor Grade works here but Google Meet still cannot access the microphone, the issue is almost certainly that meet.google.com has been blocked or has not yet been granted permission in Chrome's site settings.

When meet.google.com is blocked or uses the wrong device

Noise Floor Grade returns a reading: hardware and Chrome permission are working at the browser level, which means your Meet problem is in Meet's own device selection or in the per-site permission grant for meet.google.com specifically. In Chrome, go to meet.google.com > click the three-dot menu > Settings > Audio and verify the correct microphone appears in the dropdown with a working input level meter. If the correct device appears but the level meter does not move when you speak, the issue is that Chrome has permission to access the microphone but the specific site permission for meet.google.com has not been granted.

Noise Floor Grade fails: Chrome's microphone permission is blocked at the browser level, and the same block affects Meet because both sites depend on the same underlying Chrome permission. Go to Chrome Settings > Privacy and Security > Site Settings > Microphone to check whether Chrome has OS-level access, and verify that the specific site permission for meet.google.com is also granted.

Chrome grants microphone access on a per-origin basis, meaning capytoolkit.com and meet.google.com are treated as entirely separate permission contexts. This security design prevents a malicious website from accessing your microphone just because you granted permission to a different site, but it also means that a working Noise Floor Grade here provides no guarantee that Meet has its own separate permission grant, and you must check the permission status for meet.google.com specifically in Chrome's site settings to confirm it has been granted.

Chrome site settings on Windows and macOS

Chrome on Windows: Settings > Privacy and Security > Site Settings > Microphone > Sites that can use microphone. Verify meet.google.com is listed. Chrome on macOS: System Settings > Privacy & Security > Microphone. Confirm Google Chrome is listed and enabled. Chrome on Android: long-press the Chrome icon > App info > Permissions > Microphone > Allow. Chrome on ChromeOS: the privacy indicator in the taskbar shows active permissions. Ensure Meet has access.

On macOS, Chrome needs microphone permission at two independent levels: the macOS system level in System Settings > Privacy & Security > Microphone, and the Chrome site level for each individual website. A common failure mode is having Chrome enabled at the macOS level but having meet.google.com blocked at the Chrome site level. If the Noise Floor Grade works in Chrome on macOS but Meet does not, the macOS-level permission is already granted and the problem is specifically the per-site permission for meet.google.com within Chrome's own settings.

Microphone access across multiple Chrome profiles

Chrome manages microphone permissions independently for each user profile, and clearing browsing data including site settings wipes every stored grant for that profile.⁴ If you use multiple Chrome profiles (personal and work, for example), a microphone permission granted in one profile does not carry over to another. The Noise Floor Grade working in your personal Chrome profile does not guarantee it works in your work profile: each profile requires separate permission grants for each site that needs microphone access, including both this tool and meet.google.com. This multi-profile behavior is a common source of confusion for users who test their microphone successfully in one profile and then open Meet from a different profile where the permission has never been granted.

Permission behavior after clearing Chrome browsing data

Clearing Chrome's browsing data, including site settings, removes all stored microphone permissions for every site in that profile. After clearing, this tool and meet.google.com both require fresh permission grants. Navigate to each site, allow the permission prompt, and verify in Chrome Settings that the permission appears under each site's entry. The Noise Floor Grade provides immediate confirmation that the re-granted permission is active: if the test runs without a permission error, Chrome has successfully recorded the new grant.

Meet audio quality after hardware confirms clean

Google Meet applies its own noise suppression and audio processing to the microphone signal after it leaves the OS audio stack⁵. If the Noise Floor Grade returns Good or Excellent but participants report poor audio quality in Meet, the issue is in Meet's processing rather than the hardware. Meet's noise suppression, when applied to a signal that is already clean, can introduce artifacts: metallic voice character, speech clipping on quiet consonants, and intermittent dropout on soft syllables. These artifacts are a direct result of the noise suppression algorithm applying aggressive processing to a signal that does not need it⁶, and they are audible to every participant on the call even though your local monitoring sounds clean.

When Meet's noise suppression degrades clean hardware

In Meet's settings, navigate to Audio and set Noise cancellation to Off. If voice quality immediately improves for participants, Meet's suppression was the source. A hardware Noise Floor Grade in the Good range (below −50 dBFS) is clean enough for Meet without suppression assistance. Reserve noise cancellation for environments where the Noise Floor Grade is Noisy or worse, where it provides genuine benefit rather than processing a clean signal that did not need treatment.

Before disabling suppression, confirm the hardware baseline is actually clean by running the Noise Floor Grade in the same Chrome window you use for Meet, because a hidden per-site block or a stale profile permission would otherwise present the same symptoms as over-processing. If the grade is Good or Excellent and participants still hear artifacts, suppression is the cause and turning it off is safe; if the grade is Noisy, rule out a Chrome permission block first and fix the room instead.

When to use this

Use this test before a Google Meet call when the pre-join screen shows no microphone input, or when participants report they cannot hear you despite your microphone appearing active.

Examples

Noise Floor Grade works. Meet permission was never granted for the new Chrome profile — profiles have independent permissions

Granted microphone permission for meet.google.com in new profile settings — Meet works

Noise Floor Grade works. Chrome update reset microphone permissions for meet.google.com

Re-granted permission in Chrome site settings for meet.google.com — resolved

Microphone Not Working on Discord

With voice activity detection (VAD) as its default microphone mode, Discord uses configurable sensitivity plus a push-to-talk option.¹ Problems with Discord audio often stem from VAD sensitivity settings interacting with your noise floor; a Noisy Noise Floor Grade means Discord's voice activity detector may have trouble distinguishing your voice from background noise. A browser-based hardware test confirms the microphone is working before adjusting Discord's settings.

Discord's desktop application and browser application both use separate permission and device selection contexts.² A microphone that works in the browser app may not be the active device in the desktop app. Testing here confirms the microphone works in the browser context, the same context Discord's web app uses.³ For Discord desktop, the same confirmation at the OS level indicates the hardware is accessible to any application.

Room noise decides how well Discord voice activity works

Run the Noise Floor Grade. If the grade is Noisy or Very Noisy, Discord's voice activity detection will struggle to distinguish your voice from background noise, causing cut-in issues during speech and false activations during silence. This initial reading tells you whether the problem originates in the room environment or in Discord's configuration, because a poor noise floor will cause VAD problems regardless of how carefully you configure Discord's sensitivity slider.

Why the noise floor drives VAD reliability

Fix the noise floor first. If the grade is Good or Excellent, the noise floor is not the cause of your Discord problem and you can investigate Discord's settings directly. Discord's automatic VAD calibration samples the ambient noise level and sets a threshold just above it.¹ When the noise floor is Noisy, this automatic calibration sets the threshold too high, cutting off quiet speech and the natural ends of words. A manual VAD threshold set using a known Good noise floor gives you a more reliable starting point than Discord's automatic detection in a noisy room.

Setting Discord input sensitivity from your grade

Noise Floor Grade Noisy or worse: Discord's VAD sensitivity needs to be set manually rather than automatically because the automatic calibration will set the detection threshold too high for reliable speech detection in a noisy room. In Discord Settings > Voice & Video, disable "Automatically determine input sensitivity" and drag the sensitivity slider to a level that sits just above your measured noise floor reading but well below your average speech level, giving Discord a clear distinction between silence and speech that the automatic calibration cannot achieve when background noise is high.

Good or Excellent noise floor with Discord still not activating: Check the input volume slider in Discord Settings > Voice & Video. If it is at zero or very low, increase it. If Discord shows no device in the input dropdown, select your microphone manually from the list of available devices.

Discord input device and the Windows communications device

Discord desktop: User Settings (gear icon) > Voice & Video > Input Device dropdown. Select your microphone explicitly. Input volume slider controls the level reaching Discord's VAD. On Windows, Discord may grab the default communications device, which can differ from the default playback device.⁴ Set your microphone as the default communications device in Windows Sound settings. Discord browser: grant microphone permission for discord.com in Chrome or Firefox site settings. PTT users: confirm the PTT key binding is active and no other application is intercepting the key shortcut. When using push-to-talk, Discord bypasses the VAD entirely and transmits audio only while the key is held, which eliminates VAD-related cutout issues at the cost of requiring a key press for every speech segment.

Discord desktop on Windows grabs the default communications device rather than the default playback device, and Windows maintains these as two separate settings in the Sound Control Panel. If your USB microphone is set as the default playback device but the laptop built-in mic remains the default communications device, Discord will transmit from the built-in mic even though your USB microphone appears to be the active input in other applications. Setting both defaults to the same device eliminates this discrepancy.

Calibrating Discord VAD using your Noise Floor Grade

Discord's voice activity detection sensitivity slider determines the amplitude threshold above which Discord treats audio as speech. When set automatically, Discord samples your ambient noise level and sets the threshold just above it, but this automatic calibration assumes the ambient noise level is relatively stable and does not account for intermittent noise bursts from HVAC systems, keyboard typing, or background conversation that can cause the threshold to be set too high for reliable speech detection.

Why manual calibration beats automatic in noisy rooms

When your noise floor is Noisy or worse, Discord's automatic calibration sets the threshold too high, which cuts off quiet speech and the natural ends of sentences. Manual calibration using a known Noise Floor Grade reading gives you a more reliable starting point because you can set the threshold to a level that sits just above your measured noise floor but well below your average speech level, giving Discord a clear distinction between silence and speech that the automatic calibration cannot achieve in a noisy environment.

After adjusting the VAD sensitivity slider manually, run a validation test: join a Discord voice channel, speak at your normal volume, and confirm that your voice activates the green input indicator consistently. Then stay silent for 10 seconds and verify the indicator stays off despite ambient room noise. If both conditions are met, the threshold is correctly calibrated. If the indicator stays green during silence, drag the slider right to increase the threshold. CapyToolkit's Noise Floor Grade gives you the dBFS reading that corresponds to your silence level, which you can use as a reference for setting the Discord threshold precisely.

Managing Discord microphone state across desktop and browser

Discord desktop and Discord in a browser tab maintain separate device states. Changing the default microphone in Windows or macOS does not automatically update Discord desktop's device selection.⁵ After connecting a new microphone or switching the OS default audio input, open Discord Settings > Voice & Video and manually select the updated device. Then run the Noise Floor Grade in the browser to confirm the new device is accessible to browser applications as well.

After OS audio device changes

When you disconnect a USB microphone and reconnect it, Discord may retain the previous device selection rather than updating to the reconnected device. This is especially common in Discord desktop on Windows, where device enumeration is not always instantaneous. If Discord shows the microphone as active but no input level appears, close the device dropdown, wait five seconds, and reopen it so the reconnected device appears in the list. Running the Noise Floor Grade in a browser tab immediately after reconnection confirms the device is accessible at the OS level, so you can anchor Discord settings to the reconnected mic before opening the app.

When to use this

Use this test when Discord shows your microphone is muted or not receiving input, when people report they can barely hear you in a Discord call, or when Discord's voice activity detection cuts off your speech or activates on background sounds.

Examples

Noise Floor Grade −42 dBFS (Noisy) — Discord VAD threshold cuts audio at voice dips

Manually set VAD threshold in Discord, closed nearby window: −58 dBFS — smooth conversation

Noise Floor Grade works in browser. Discord desktop still showing old headset as active device

Selected new headset in Discord Settings > Voice & Video input dropdown — resolved

Microphone Not Working on Android

On Android, microphone access is governed by both OS-level permissions and app-level permissions, with Chrome adding its own permission layer for browser-based audio access. Chrome on Android uses getUserMedia to request microphone access, which requires both the Chrome browser app to have microphone permission in Android settings and the specific website to be granted permission within Chrome. Both layers must be correct for browser-based audio tools to work.¹

Browser-based microphone testing on Android uses the same getUserMedia path that Google Meet, WhatsApp web, and other web-based voice applications use. If the Noise Floor Grade works in Chrome on Android here, the microphone is accessible to all Chrome-based web applications. If it fails, the permission issue affects all browser-based voice access, not just this tool.

Running the test in Chrome on Android

Open Chrome on Android and navigate to this tool. Grant microphone permission when prompted. Run the Noise Floor Grade. If the test returns a grade, even if the number is poor, the microphone hardware, Android OS permission, and Chrome permission are all correctly configured. A successful test result proves that the signal path from the Android microphone capsule through the OS audio stack to the Chrome browser is fully functional, which means any web-based voice application on the same device should also be able to access the microphone.

Two independent permission layers block access

If the test fails with a permission error, the issue is in Chrome or Android permission settings. Android requires two independent permissions for browser-based microphone access: the Chrome app must have microphone permission at the OS level, and the specific website must have microphone permission within Chrome's site settings. Both must be granted for the Noise Floor Grade to work. If either layer is denied, the browser cannot access the microphone, and neither can any web application running in that browser.¹

When Chrome hears you but another app does not

Noise Floor Grade returns any result: microphone access is working in Chrome, which means the Android OS permission and Chrome app permission are both correctly configured. The problem with your specific application may be in that app's own permission or configuration, since each Android app manages its own microphone permission independently.

Noise Floor Grade shows "Permission denied": go to Android Settings > Apps > Chrome > Permissions > Microphone > Allow, and check the per-site permission for the specific website. If Chrome has permission but specific sites do not, go to Chrome Site Settings (Chrome menu > Settings > Site settings > Microphone) and check the blocked list.

Microphone permission paths on stock Android, One UI and MIUI

Stock Android: Settings > Privacy > Permission manager > Microphone > Chrome. Ensure it shows "Allow only while using the app." Samsung One UI: Settings > Privacy > Permission manager > Microphone > Chrome. MIUI (Xiaomi): Settings > Apps > Chrome > App permissions > Microphone > Allow. For specific websites in Chrome: tap the site info icon in the Chrome address bar > Microphone > set to Allow. Some Android OEMs add an additional OS-level microphone access layer in their privacy settings. These manufacturer-specific layers operate below the standard Android permission model and can block microphone access even when Chrome and individual websites appear to have all necessary permissions granted at the standard Android level.

Unlike a standard Android permission denial that shows an explicit error message, manufacturer privacy layers often block microphone access silently by returning an empty audio stream rather than throwing a permission error. This means the Noise Floor Grade may return a result that looks valid but actually represents digital silence rather than real room noise, making it appear as though the microphone is working when in fact no audio data is reaching the browser at all.²

Manufacturer permission layers on custom Android builds

Beyond the standard Android permission model, several major Android manufacturers add additional privacy controls that intercept microphone access before Chrome's own permission layer. These manufacturer overlays are separate from Android's standard Privacy Manager and can block microphone access even when both Chrome and individual websites appear to have permission granted. If the Noise Floor Grade fails in Chrome despite all standard permissions appearing correct, a manufacturer-specific permission layer may be the cause.³

HarmonyOS and Xiaomi MIUI additional permission layers

On Xiaomi MIUI devices, navigate to Settings > Apps > Chrome > App permissions > Microphone, but also check Security > Privacy protection > Permission management, which maintains a separate microphone access list. On Huawei devices running HarmonyOS, check Settings > Privacy > Permission manager > Microphone > Chrome, distinct from the standard Android path. Samsung One UI adds a Camera and Microphone Usage indicator in the status bar; if it shows blocked, check Settings > Privacy > Permission manager. After granting access through all applicable layers, reload this page and retry the Noise Floor Grade.

Run the Noise Floor Grade again only after every applicable permission layer has been granted, because a partially-granted state can return a silent or empty stream that looks like success while delivering no real audio. If the retry still shows digital silence, the missing layer is almost certainly one of the manufacturer overlays rather than the standard Android permission, and the device-specific privacy menu is the place to look next.

Testing across browsers to isolate Chrome-specific issues

If the Noise Floor Grade works in Firefox on Android but fails in Chrome, the issue is Chrome-specific rather than at the Android OS level. Chrome and Firefox maintain independent permission states. A microphone permission granted in Firefox does not satisfy Chrome's permission requirement for the same site.⁴ Testing in both browsers establishes which layer is responsible. OS-level failures affect all browsers simultaneously; Chrome-level failures affect only Chrome.

Device management policy as a root cause

On Android devices enrolled in corporate mobile device management (MDM), a management policy can restrict microphone access for specific applications, including Chrome. This restriction applies silently: Chrome requests microphone permission and the OS appears to grant it, but the MDM policy intercepts the audio stream before it reaches the app. If your device is managed by an organization and microphone access fails in Chrome despite all standard permissions appearing correct, trace the Android mic permission layers and then contact IT support. The fix requires a policy change that only the domain administrator can apply.⁵

When to use this

Use this test when voice features fail in Chrome on Android, such as voice messaging, Google Meet web, or AI voice assistants, to distinguish hardware failure from permission configuration issues.

Examples

Noise Floor Grade fails with permission error — Chrome's microphone permission was reset by Android update

Re-granted microphone permission in Android App Settings for Chrome — voice calls restored

Noise Floor Grade in Chrome fails. Native camera app works — Chrome-level permission was blocked

Allowed microphone for Chrome in Android permissions — Chrome-based tools now work

Laptop Microphone Not Working

When a laptop microphone fails, the cause is usually hardware access or software configuration: a physical privacy shutter, disabled audio controller, driver conflict, permission denial, or exclusive mode conflict. A browser-based test distinguishes these immediately: if the Noise Floor Grade returns any reading, the hardware and OS driver are functioning. If it fails entirely, the hardware or its driver is the issue.

Built-in laptop microphones are often listed as two separate devices in the OS: a standard microphone input and an "array" microphone that includes the laptop's beamforming or noise reduction firmware.¹ Applications may be accessing different devices than expected. Testing here confirms which device the browser selects by default, and that is the same device most browser-based applications will use.

Mute keys and privacy switches on laptops

Run the Noise Floor Grade. getUserMedia() resolves only once the permission prompt is accepted, and its MediaStream reflects whichever capture device the OS hands the browser by default.² Any result, any grade at all, means the hardware is working. On laptops specifically, check for a physical privacy shutter or microphone mute button before investigating any software setting: some laptop models include these on the keyboard or as a physical slider above the screen bezel.

Ruling out physical disconnection before software troubleshooting

These physical switches disconnect the microphone at the hardware level and appear as complete silence or a "device not found" error in the test. The Clipping Detector running while you tap near the keyboard confirms whether the microphone is physically active and receiving vibration through the chassis. If the detector shows no response to tapping but the Noise Floor Grade returns a valid reading, the microphone is active but positioned far from the keyboard, which is common on laptops with top-bezel microphone placement. Checking for physical disconnection first prevents spending time on software troubleshooting for a problem that a single hardware switch controls.

Built-in microphone failures that USB mics do not have

Noise Floor Grade succeeds: hardware is working. Check which device is selected in OS audio settings and verify applications use the intended device. If the noise floor grade is Very Noisy, the laptop's built-in microphone may be picking up keyboard sounds and fan noise, which is common on thin-and-light designs.

This is a hardware limitation, not a defect. Noise Floor Grade fails completely: check the physical mute switch, OS microphone permissions, and whether audio enhancements or exclusive mode in Windows have locked the device. When the Noise Floor Grade fails on a laptop, the most common cause is a physical privacy shutter or keyboard mute button that disconnects the microphone at the hardware level before any software setting can override it.

Built-in laptop microphones are subject to more failure modes than external USB microphones because they depend on the laptop's internal audio controller, which can be disabled by power management settings, BIOS configuration, or driver conflicts that do not affect USB audio devices.³ Additionally, many modern laptops include a hardware privacy switch or keyboard shortcut that physically disconnects the microphone circuit, producing a "device not found" error that no software troubleshooting can resolve until the physical switch is returned to its enabled position.

Windows privacy, exclusive mode and macOS permission on a laptop

Windows 11: Settings > Privacy & Security > Microphone, and ensure apps are allowed. The underlying reason a browser capture can fail on an otherwise healthy device is that the Windows privacy layer gates microphone access per application, and each app must be enabled individually rather than inheriting a global on state.⁴ Sound Control Panel > Recording tab, then right-click to show disabled devices and enable if the microphone appears disabled. Exclusive mode: right-click the microphone > Properties > Advanced > uncheck "Allow applications to take exclusive control." macOS: System Settings > Privacy & Security > Microphone, and ensure your browser is listed and enabled. Linux: check if PulseAudio or PipeWire is running; use pactl list sources to confirm the microphone appears as an available source.

When Windows Exclusive Mode is enabled for a built-in laptop microphone, the first application to open the device locks it for exclusive use, preventing all other applications from accessing the microphone simultaneously.⁵ This means that if a conferencing application opens the microphone in exclusive mode, the browser-based Noise Floor Grade test will fail with a device error even though the microphone hardware is functioning perfectly. Disabling Exclusive Mode in the microphone's Advanced Properties allows multiple applications to share the device, which is the expected behavior for most users who need the microphone available to both browser tools and desktop applications at the same time.

Choosing between the array and standard microphone entry

Most Windows laptops list two microphone entries in the Sound Control Panel Recording tab: a standard entry for the raw microphone signal and an array entry for the beamforming-processed version. The array entry applies the laptop's own noise reduction and directional filtering before the OS delivers audio to applications. The standard entry delivers the unprocessed capsule output. Which one produces the better Noise Floor Grade depends on the specific laptop model and the room's acoustic conditions at your current position.

Which entry gives better results for AI voice services

Run the Noise Floor Grade with each entry selected as the default recording device and compare the readings. The array entry often returns a better grade in ambient noise environments because beamforming reduces off-axis sound pickup.¹ In a quiet room, the raw entry may return a better grade because the array processing introduces its own noise artifacts. For AI voice services, the array entry's directional focus generally helps more than it hurts: it reduces the background noise that would otherwise interfere with speech recognition accuracy.

Preventing incorrect device selection after connecting external audio

Windows separates the Default Device and the Default Communication Device in the Sound Control Panel. The Default Device is used by music players, system sounds, and most general audio applications. The Default Communication Device is used specifically by communication applications like Teams, Zoom, and most VoIP software. Your browser uses the Default Device for microphone input unless an application explicitly requests the Default Communication Device.⁶ Setting your preferred microphone as both prevents the situation where the browser's Noise Floor Grade test and Teams use different physical devices.

Default Communication Device versus Default Device on Windows

Before you align the browser mic with your call device, right-click your preferred microphone in Sound Control Panel > Recording tab and use both Set as Default Device and Set as Default Communication Device (two separate right-click options). After making this change, run the Noise Floor Grade here to confirm the browser is using the intended device. If Teams previously showed a different device, open Teams Settings > Devices and verify it has updated to the new default, or manually select the preferred microphone from the dropdown.

Perform the two right-click actions every time you add or remove an audio device, because Windows does not always carry the Default Communication Device over when a new microphone appears in the Recording tab. A browser Noise Floor Grade that uses the Default Device while your call software uses the Default Communication Device is the exact split that produces a working test and a dead call. Re-checking both entries after each hardware change keeps the two in agreement.

When to use this

Use this test when the laptop's built-in microphone stops working unexpectedly, after a software update, when you have connected an external microphone and applications are accessing the wrong device, or to confirm which microphone device the browser is actually using.

Examples

Noise Floor Grade fails after update reset, and the microphone is listed as disabled in Windows Sound Control Panel

Enabled microphone in Sound Control Panel, confirmed OS permission: Noise Floor Grade Excellent

Noise Floor Grade shows noisy result because the browser defaults to the built-in laptop mic instead of the USB device

Set USB microphone as Windows default input device: browser now uses USB, Excellent noise floor

Microphone Not Working on Windows 11

On Windows 11, layered microphone privacy controls can block microphone access at multiple independent levels: the Microsoft Store apps layer, the desktop apps layer, and individual app permissions.¹ A browser-based test bypasses all Windows application layers and tests microphone access at the most fundamental level, the OS audio driver, which tells you immediately whether the microphone hardware is functioning before investigating application settings.

Windows 11 also adds audio enhancements (Noise Suppression, Echo Cancellation, Automatic Gain Control) that apply at the OS level before any application receives the audio stream. The Noise Floor Grade and Clipping Detector in this tool measure the post-enhancement signal, so they reflect exactly what applications receive. Enhancements causing problems, such as processing artifacts and unexpected gain changes, appear in these test results before any specific application is involved.

A clean baseline with audio enhancements off

Run the Noise Floor Grade. Any result confirms the microphone driver is working and OS-level access is not blocked. The result grade also reflects the current Windows audio enhancement settings. For a clean hardware baseline, run the test with audio enhancements disabled via Sound Control Panel first so that the reading reflects only the microphone and room without any software processing applied.

Isolating which enhancement shifts the reading

Then enable enhancements one at a time and compare grades after each change to quantify the individual effect on noise floor. This before-and-after comparison reveals which specific enhancement shifts the reading the most, and that information tells you whether the processing is helping or degrading your signal. If the grade worsens after enabling a particular enhancement, leave that one disabled and move to the next. The goal is to identify the combination of enhancements that produces the best Noise Floor Grade for your specific microphone and room combination.

Windows privacy settings versus each app's device choice

Noise Floor Grade succeeds: hardware and driver are functioning at the OS level, which means the microphone is physically working and the problem is in the application-specific Windows Privacy settings or the individual application's device selection rather than in the hardware or driver. This narrows the troubleshooting path to three areas: the Windows privacy toggles, the specific application's microphone permission, or the application's cached device selection that may be pointing to a disconnected microphone.

Noise Floor Grade fails with permission error: go to Windows Settings > Privacy & Security > Microphone and check all three settings: "Microphone access," "Let apps access your microphone," and "Let desktop apps access your microphone." All three must be On for standard applications to receive microphone input, and the third toggle is the one that most commonly gets reset to Off by Windows updates without the user noticing, which silently blocks every desktop application from accessing the microphone until the toggle is manually re-enabled. The three-toggle design in Windows 11 is a common source of confusion because "Microphone access" can be On while "Let desktop apps access your microphone" remains Off, which blocks Chrome, Firefox, and other desktop browsers from accessing the microphone even though the global toggle appears to be enabled.

The three-toggle architecture separates Microsoft Store apps (UWP) from desktop applications (Win32) because these two application types use different audio APIs and permission models. Store apps use the modern Windows.Media.Capture API, while desktop applications use the legacy WASAPI or DirectSound APIs. A desktop browser like Chrome falls under the "desktop apps" toggle, which means it can be blocked independently of the global "Microphone access" toggle.² Checking all three settings in sequence is the fastest way to identify which layer is blocking your specific application.

Windows privacy toggles and the Sound Control Panel

Windows 11 Privacy: Settings > Privacy & Security > Microphone, and confirm all three toggles are On. Sound Control Panel: right-click Start > Sound settings > More sound settings > Recording tab, then right-click your microphone and Enable if disabled. Right-click > Properties > Advanced > uncheck Exclusive Mode if applications compete for device access. Audio enhancements: right-click microphone in Recording tab > Properties > Enhancements; disable all or test individual enhancements. Driver rollback: Device Manager > Sound > right-click audio device > Update driver > Browse my computer > Let me pick from a list to roll back after a problematic update.

If a Windows update installs a new audio driver that changes your Noise Floor Grade from Good to Noisy, rolling back to the previous driver via Device Manager restores the previous behavior immediately without waiting for Microsoft to release a fix. The rollback option is available in Device Manager > Sound > right-click audio device > Properties > Driver > Roll Back Driver, but only if Windows has retained the previous driver package. If the rollback option is grayed out, the previous driver was cleaned up during the update, and you will need to download the manufacturer's driver directly from their support site to restore the previous behavior.³

Diagnosing audio driver conflicts after Windows updates

Windows updates can install new audio driver versions or revert to generic Windows Audio Subsystem (WAS) drivers from manufacturer-specific ones. A driver change during an update may change the Noise Floor Grade result significantly: generic WAS drivers sometimes apply different default buffer sizes or enable audio enhancements that were disabled under the manufacturer driver. After any Windows update that changes audio behavior, run the Noise Floor Grade immediately to establish the post-update baseline before investigating any specific application.

Manufacturer audio suites applying independent processing

Asus, HP, Dell, and Lenovo ship laptops with proprietary audio suites (Sonic Studio, HP Audio Control, Dolby Access, Lenovo Audio) that apply processing outside of the Windows audio enhancement framework. These suites operate at the driver level and are not disabled by the Windows Sound Control Panel Enhancements settings.⁴ If the Noise Floor Grade remains unexpectedly high after disabling all Windows enhancements, check whether a manufacturer audio suite is installed and temporarily disable it from its own application settings to isolate its contribution to the measured floor.

Treat the manufacturer suite as a fourth layer beneath the three Windows privacy toggles, because it sits at the driver level where the Sound Control Panel Enhancements tab cannot reach it. If the Noise Floor Grade stays high after every Windows enhancement is off, open the vendor's own audio application and look for a master processing toggle rather than assuming the OS is the last word. The extra step resolves cases that look like hardware failure but are really suite-side processing.

Maintaining consistent microphone access across Windows sessions

On personal Windows 11 machines, microphone access settings persist across reboots once configured correctly. If microphone access fails consistently after reboots rather than only after specific events, consider two causes: an application at startup that takes exclusive device control, or a scheduled task that modifies audio settings. The Clipping Detector running while you speak confirms whether input audio is reaching the browser even when the Noise Floor Grade appears blocked by permission issues.

Enterprise group policy as a root cause

On Windows 11 machines managed by an organization through Group Policy, a GPO rule can block microphone access for browser applications regardless of what Windows Privacy Settings shows. GPO rules override user-level settings silently and without obvious error messages.⁵ If your machine is managed by an organization and microphone access fails despite all privacy settings appearing correct, run the Noise Floor Grade from a personal unmanaged device on the same network to pinpoint the GPO mic block on Windows before contacting IT. Then contact IT support: the fix requires a GPO policy change that only the domain administrator can apply.

When to use this

Use this test after any Windows 11 update that changed audio behavior, when setting up a new microphone, when browser-based voice applications suddenly stop working, or as the first diagnostic step before filing a support request about Windows audio.

Examples

Noise Floor Grade permission error after Windows update reset "Let desktop apps access your microphone" to Off

Turned on all three microphone privacy toggles in Windows Settings, and all applications were restored

Windows Automatic Gain Control enhancement enabled and changing microphone level unpredictably

Disabled AGC enhancement via Sound Control Panel Properties > Enhancements for consistent volume