Clear the microphone first: prove it works so only the app is left
When friends on Discord cannot hear you, when Zoom shows a line through your microphone icon, or when teammates in a game get silence, the instinct is to assume the microphone has died. But if the same microphone works perfectly somewhere else, the microphone is not the culprit. This guide is about exactly that situation: the hardware is alive, and one particular program is failing to receive what it produces. If the microphone does not respond anywhere, our guide on a microphone that is not working is the place to start instead.
Begin by collecting evidence that the microphone works. Open our mic test, allow access when the browser asks, and speak. If the input level meter rises and falls with your voice and the real-time waveform moves, then the microphone, its cable and the operating system's basic handling of it are all fine. Use the short record and playback feature to hear yourself and confirm the quality too. Once you have a clean result here, the list of suspects shrinks to the problem app and the settings that surround it.
This matters because it changes the direction of the whole investigation. A microphone that is dead everywhere sends you to cables, jacks, drivers and mute switches. A microphone that is dead in one place sends you somewhere completely different: which device that app is listening to, whether the operating system has allowed that app to use the microphone at all, and whether some other program has taken exclusive hold of the device. A great deal of time gets wasted reinstalling drivers and swapping cables for a problem that lives entirely in software settings.
One more thing to note while you are in our test is the list of names in the input device selector. That list is every recording device the operating system currently knows about, and it becomes your reference when you compare it with the device list inside the app. If you see a webcam microphone, a laptop's built-in microphone, or a virtual device with an unfamiliar name alongside your headset, remember them. Most of the traps described below hide in that list.
Three places choose the microphone, and they can disagree
A computer does not have one microphone setting; it has three. The first is the operating system's default input device. The second is the input device each application remembers in its own settings screen. The third, for anything that runs in a browser, is the browser's own per-site device choice and permission. When these three point at different devices, you get the classic result: our test hears you clearly through the headset while Discord is listening to the webcam and a game is waiting on a microphone you unplugged last week.
It also matters whether an app is set to 'Default' or to a specific device by name, because the two behave differently. With Default, the app follows whatever the operating system currently calls the default input, which sounds convenient, but every time you plug in or remove a headset the operating system may quietly switch the default, and the app switches with it without telling you. A named device is stable, but if that device is unplugged or its name changes, the app fails silently rather than falling back to something else. Windows sometimes registers the same microphone as a new device when you move it to a different USB port, which is another way the saved name and the real device can drift apart.
The fix is to make all three agree. On Windows, choose the input device under Settings, System, Sound. On macOS, open System Settings, Sound, and the Input tab. Then open the problem app, find its voice or audio settings, and select the exact device that moved the meter in our test. If your peripherals change often, naming the device explicitly rather than leaving Default, and glancing at the app's settings whenever you change hardware, is the least painful routine over the long run.
Per-app microphone permissions and exclusive mode
If the operating system sees the microphone but one app shows an empty device list or receives silence, per-app permissions are the first thing to check. On Windows, open Settings, then Privacy and security, then Microphone. There is a master switch for microphone access, a switch allowing apps to use the microphone, and an individual list of apps installed from the Store. Below that is a separate toggle allowing desktop apps to access the microphone, and programs installed from an ordinary installer, which includes Discord and most games, fall under that toggle. When it is off, you get precisely the symptom this guide is about: the browser works and desktop programs go quiet.
On macOS, open System Settings, Privacy and Security, and Microphone to see a list of apps with checkboxes. The crucial detail is that macOS only adds an app to this list after the app has asked for the microphone at least once. If the app is missing from the list, it has either never asked or its request failed, so quit it completely and relaunch it so that the permission dialog appears. If you accidentally clicked Don't Allow the first time, simply turn the checkbox on here, and restart the app afterwards to be safe.
If permissions are all in order and one app still cannot open the microphone, another program may be holding the device exclusively. In the classic Windows Sound control panel, open the microphone's properties from the Recording tab and look at the Advanced tab for the option that allows applications to take exclusive control of the device. When it is enabled and some program has grabbed the device in exclusive mode, every other app sees the device but gets nothing from it. Turn the option off, close any voice, recording or manufacturer audio utilities running in the background, and try again. Note that our own test tab is holding the microphone open while it runs, so when you test the app, close the test tab or switch away from it to release the device, or the comparison is not fair.
App-specific traps: Discord, Zoom, Teams and Google Meet
Discord keeps separate input and output device pickers under Voice and Video, with input sensitivity just below them. When automatic input sensitivity is on, a quiet microphone can be classified as background noise and never transmitted, so turn the automatic option off and slide the threshold to the left until the green bar clears the line when you speak normally. If the input mode is set to push-to-talk rather than voice activity, nothing goes out unless you hold the assigned key, and forgetting a key you set months ago is remarkably common. Noise suppression and the voice processing options in the advanced section can also strip out a voice they misjudge, so for diagnosis turn them all off and compare.
Zoom has its own trap at the moment you join: if you skip the step that joins with computer audio, you will see a microphone icon but nothing you say will reach the meeting. Click the arrow beside the microphone icon at the bottom of the window to see which microphone is currently selected, then look in the audio settings at the option to automatically adjust microphone volume and at the background noise suppression level. The original sound option, intended for music, bypasses Zoom's processing entirely, which makes it a handy way to test whether noise suppression is what is eating your voice.
Teams needs you to select the microphone explicitly under Settings and then Devices, reached from your profile menu, and during a meeting you can reopen device settings from the More menu at the top. With noise suppression set to High, some microphones sound as if the voice is being chopped, so try Low or Auto for comparison. Google Meet in a browser needs two checks: click the site information icon in the address bar and confirm the microphone permission is set to Allow, and then confirm the browser is not using a different default microphone from the operating system. Browsers remember their own per-site microphone choice, so pick the microphone explicitly in Meet's settings rather than trusting the default. Our test runs in the same browser, so all you have to do is match the device name that moved the meter there with the one you select in Meet.
Games, Steam, OBS, and the virtual audio device that quietly became your default
Most games have their own voice chat settings with a separate input device and activation mode. In games where push-to-talk is the default, Valorant among them, nothing transmits unless you hold the assigned key, and an input device left at Default follows the operating system's default device with all the drift that implies. Steam maintains yet another layer: Settings, then Voice, has its own input device, transmission mode and a built-in microphone test. If your voice chat runs through the Steam overlay rather than the game's own system, this is the screen that matters, not the game's. On Windows, the Xbox Game Bar can also capture the microphone during game recording; if you do not use recording, turning off microphone capture in Game Bar's audio options removes one more program competing for the device.
OBS can take a microphone in two different ways, and mixing them causes confusion. One is the Mic/Auxiliary Audio device set under Settings, Audio. The other is an Audio Input Capture source added directly to a scene. Use one or the other; putting the same microphone into both doubles your voice. Watch the microphone track in the Audio Mixer while you speak, and if the meter does not move, reselect the device in that source's properties. If the meter moves but you cannot hear yourself in your headphones, that is normal: OBS does not monitor the microphone by default, and you have to enable monitoring in Advanced Audio Properties if you want to hear it.
The hardest trap to spot is a virtual audio device. Software such as Voicemeeter, VB-Cable, NVIDIA Broadcast and SteelSeries Sonar installs a virtual microphone under its own name and frequently makes it the operating system's default input. From then on, apps listen to the virtual microphone, and the virtual microphone only carries your real microphone's signal while that software is running and routed correctly. Quit the program, disable it from starting with Windows, or knock its routing out of alignment, and every app is listening to an empty pipe. In our test's device selector, if the meter moves when you pick your real microphone and sits still when you pick the virtual device, either select the real microphone directly in the app or repair the routing in the virtual audio software.
Bluetooth headsets cause a similar kind of confusion. One physical headset shows up in Windows as two devices: a stereo profile for listening to music, and a hands-free profile for calls. Only the hands-free device has a microphone. An app can happily use the stereo device for output, but its input must be the hands-free device, and if the hands-free device has been disabled the microphone appears nowhere at all. In the Sound control panel's Recording tab, check that the headset's hands-free entry is enabled. The drop in output quality while the hands-free profile is active is a characteristic of the profile itself and cannot really be avoided with settings.
A recommended checklist order
Work through it in this order. First, confirm in our mic test that the meter and waveform respond and a recording plays back, which removes the microphone and the operating system from suspicion, and note the exact name of the device that moved the meter. Second, check the operating system's per-app microphone permissions: the desktop apps toggle on Windows, and on macOS both the checkbox for the app and whether the app appears in the list at all. Third, open the problem app and select the input device by that exact name. Naming the device rather than leaving Default is the surest way to stop the problem coming back.
Fourth, check the app's transmission conditions: the push-to-talk key, the input sensitivity threshold, automatic sensitivity, and whether you actually joined the meeting's audio. The device can be correctly selected and still send nothing if one of these gates is closed. Fifth, switch off noise suppression and voice processing and compare, to rule out a voice that is being erased rather than never captured. Sixth, disable the exclusive mode option, close background voice, recording and manufacturer audio utilities as well as our test tab, and try again.
Finally, if the device list shows a virtual audio device or a Bluetooth hands-free device, check whether it has silently become the default, or in the Bluetooth case whether it is the device you actually need to select. Followed in this order, most cases of a microphone that fails in only one app end with a few settings corrected and the microphone itself untouched. If the app is fixed but people still say you are quiet or noisy, our guides on a microphone that is too quiet and on microphone echo and noise are the next step.