Microphone Test

Introduction

The DeviceHub Microphone Test is a free online microphone check that measures live input levels directly in your browser without downloads, accounts, or plugins. Open the page, grant microphone permission when prompted, and speak at a normal conversational volume while an on-page meter shows whether your laptop array, USB headset, Bluetooth earbuds, or studio interface is delivering signal to the web platform. The tool uses getUserMedia for capture and the Web Audio API for local analysis, the same foundation Zoom, Teams, Meet, and Discord rely on, so a working result here is a strong baseline before you blame a single meeting app. Remote workers before client calls, podcasters warming up, gamers joining voice chat, students in virtual classrooms, call-center agents, and help-desk staff use it as a neutral first step when someone reports “they cannot hear me.” If you swapped headsets, updated the OS, muted a hardware switch, or suddenly lost input in every app, this browser meter answers the fundamental question, does the mic produce usable levels in a normal web context, in seconds rather than minutes of driver reinstalls.

What this tool does

This tool opens an audio MediaStream through getUserMedia, routes samples into a Web Audio AnalyserNode, and displays a live level meter plus a percentage-style readout so you can see how strongly the browser receives your voice. After permission is granted, mediaDevices.enumerateDevices() reveals audioinput labels so you can switch among built-in mics, headsets, and interfaces without leaving the tab. Status panels summarize track readiness, negotiated sample rate and channel count when available from MediaStreamTrack.getSettings(), and the active device label. Permission state is surfaced early so a blocked site is obvious before you chase drivers or reinstall conferencing software. Stopping the test calls track.stop() on each audio track so the OS microphone indicator turns off and other applications can reclaim the device. The intent is a complete microphone smoke test: open, speak, confirm the correct capsule is selected, verify the meter rises and falls with speech, then release hardware cleanly.

When to use it

Use the Microphone Test before job interviews, client calls, webinars, livestreams, podcast recordings, proctored exams, and telehealth visits when you need confidence the mic works outside a single vendor app. Run it after docking or undocking a laptop, after installing OS updates that reset privacy toggles, after plugging in a USB headset or audio interface, and whenever a meeting app shows “no input” while other programs seem fine. IT teams can ask users to open this page so both sides share a common baseline outside Zoom or Teams configuration layers. Content creators verifying a new capsule or interface path benefit from an independent meter that does not depend on DAW monitoring or virtual cable routing. Parents helping kids with school laptops use it to confirm the built-in mic before an exam platform locks device selection. If you only need ambient noise trends, latency estimates, or an echo loop check, jump to those specialized audio tools; start here when you need human-readable proof that speech moves the meter. Call-center supervisors also bookmark this page as a shared triage link when agents report intermittent mute across softphones, because a browser meter that rises with speech proves the OS path before vendors blame SIP trunks. Accessibility teams verifying live-caption readiness use the same smoke check so capture exists before enabling transcription features in meeting software.

How it works

On Start, the page calls navigator.mediaDevices.getUserMedia with an audio constraint object and omits video so the test stays focused on input capture. The browser prompts for microphone permission through the Permissions API flow if the site is not already allowed for this origin. After the promise resolves, the returned MediaStream feeds a Web Audio AudioContext graph, typically a MediaStreamAudioSourceNode into an AnalyserNode, where time-domain samples yield an RMS-style level for the on-page meter. Track settings are read from MediaStreamTrack.getSettings() to surface sampleRate and channelCount when the browser exposes them. Device labels come from mediaDevices.enumerateDevices() after a successful capture grant; labels are often empty strings before permission for privacy reasons. Stopping the test ends every MediaStreamTrack so exclusive locks clear for other apps. Secure context over HTTPS or localhost is required for getUserMedia in modern Chromium, Firefox, and Safari builds. DeviceHub does not upload PCM buffers: analysis stays in tab memory for visualization only during the active session. AnalyserNode FFT sizes influence how quickly the meter reacts to plosives versus sustained vowels; DeviceHub tunes for readable speech feedback rather than studio ballistic VU ballistics. If the AudioContext is suspended by autoplay policies, the first user gesture that starts capture also resumes the context so meters are not stuck at zero for policy reasons. GroupId hints from enumerateDevices can show when a headset’s mic and headphone share one composite USB device, which helps explain why unplugging headphones also removes the input you just selected.

Step-by-step instructions

1. Open this DeviceHub page over HTTPS in Chrome, Firefox, Edge, or Safari and locate the interactive Microphone Test panel where the level meter and Start control will appear once you begin capture.
2. Click Start microphone and choose Allow when the browser permission dialog requests access to your microphone, because denied permission is the most common reason a meter never moves even when hardware works elsewhere.
3. Speak at a normal volume about an arm’s length from the capsule and watch the live meter rise with speech and fall toward silence when you pause, confirming the browser receives a usable signal path.
4. If multiple inputs are connected, open the device picker after permission, select your intended headset or USB microphone from the audioinput list, and speak again to confirm levels follow the newly selected device.
5. Optionally whisper, then speak louder, to see how gain and distance affect the readout, useful when diagnosing auto-gain behavior that conferencing apps hide until you are already live on a call.
6. Click Stop when finished so every MediaStreamTrack ends through track.stop(), the operating-system mic-in-use indicator turns off, and other applications such as Teams or Discord can reclaim the microphone without closing the browser.

Common problems

A flat zero meter usually means denied permission, a muted OS input, the wrong device selected, a hardware mute switch on the headset, or another app holding exclusive access through ASIO or similar drivers. Peaks that barely rise may indicate gain set too low in system sound settings or Bluetooth hands-free profiles that throttle quality. Constant high levels with no speech can suggest electrical noise, a stuck-open gain control on an interface, or a feedback loop if speakers are monitoring the same room. Generic labels like “Microphone 1” appear until permission is granted for enumerateDevices to reveal friendly names. Mobile browsers may need a full reload after you change site microphone access in system settings. If levels work here but fail in one meeting app, investigate that app’s device picker, noise suppression pipeline, or exclusive mode next rather than replacing hardware immediately. Enterprise endpoint protection that blocks getUserMedia by policy produces permission failures that look identical to user denial, check managed browser policies when every site fails. Some USB headsets expose both an analog jack mic and a USB ADC; selecting the wrong one yields silence while the LED on the boom still lights. Acoustic echo cancellation in the OS can attenuate your voice if speakers play nearby content; mute tabs and retest. After sleep/resume, deviceIds occasionally reshuffle, reopen the picker rather than assuming yesterday’s default remains correct.

Privacy explanation

Your microphone stream stays entirely on your device during this test without cloud relay. Audio samples are analyzed in memory for level visualization only; they are not uploaded, recorded, transcribed, or stored on DeviceHub servers at any point in the session. When you click Stop, all active tracks end immediately and the site releases the microphone so hardware indicators should extinguish on supported systems. You remain in full control through browser site settings and can revoke microphone access for this origin anytime. No session archive or voiceprint is created after you navigate away. Clearing cookies does not by itself revoke microphone grant; use explicit site permission controls instead. DeviceHub never ships microphone PCM to analytics endpoints, crash reporters, or third-party CDNs during this diagnostic. Permission prompts are the browser’s own UI; DeviceHub cannot silently re-enable a revoked mic. If you share a screen recording of the meter for support, blur any visible desktop content you do not intend to disclose.