Home / Troubleshooting / Mic Troubleshooting
TroubleshootingMic Troubleshooting
Work through microphone faults in the order that finds them fastest, from permissions down to hardware.
Mic troubleshooting works best from the outside in: browser permission, then app selection, then Windows or macOS input device, then cable and port, then driver. Test at each layer instead of changing everything at once.
Mic Troubleshooting — how to do it
- Test in the browser first
The console above gives an immediate yes or no. A working browser test eliminates hardware, driver and system permission in a single step.
- Check the app that failed
Every application selects its own input. Open its audio settings and choose the same device you tested with here.
- Check the system default
Operating systems change the default input silently when devices are connected. Confirm yours is still selected.
- Check permission
Windows, macOS, iOS, Android and ChromeOS all gate microphone access per app. A single toggle can silence everything.
- Check the physical layer
Cable seated fully, correct socket, mute switch off, boom rotated down. Try a different port and, if possible, a different machine.
- Only then look at drivers
If the browser test fails on every device and port, and the device shows a warning in Device Manager, a driver is genuinely at fault.
Symptoms and their usual causes
- IntermittentA cable failing near a stress point, a loose port, or a Bluetooth link struggling. Wiggle-test while watching the meter.
- Complete silence everywhereSystem-level permission or a hardware mute. Both produce a perfectly flat meter with no error message anywhere.
- Works in one app onlyExclusive mode, or per-app permission. The first app to claim the device can lock the others out.
- Very quietDistance or input volume. Check the level in the console before changing anything else.
- DistortedGain too high or the microphone is too close. The clipped-frame counter confirms it immediately.
Test at every layer, change nothing until you know
Microphone audio passes through at least five layers between a capsule and a listener: hardware, driver, operating system routing, permission, and the application. A fault at any one produces the same symptom — silence — which is why guessing is so ineffective.
Testing at each boundary turns a mystery into a location. The browser test sits near the top of the stack, so a pass there means everything beneath it is healthy and only the application layer is left. That single result eliminates most of the advice you will find elsewhere.
Common questions
How do I know if it is hardware?
Test the same microphone on a different computer. If it fails there too, it is hardware.
Why does it work sometimes?
Intermittent faults are cables, connectors and radio links. Software faults are consistent.
What information should I give support?
The Report panel above produces a copyable summary with device name, sample rate, processing state and measured levels.
What should I check first?
Whether the browser can hear you. It is the fastest single test and it rules out four layers at once.
Related tests
Where to go next: the driver checklist, sorting out audio drivers, or whether a driver is really at fault.
Tested and updated · Written and maintained by check-mic.com · Report a problem with this page