MIC
TEST

A microphone that is not working is usually not broken. The signal passes through five links between the air in front of your face and the software that wants your voice, and each link belongs to different hardware or different software, built by different people.

That is what makes the symptom so hard to read. A capsule can be in perfect physical order and produce no electricity at all. An operating system can be receiving audio and hand an application silence. A browser can hold a permission you granted weeks ago and still deliver nothing but zeros.

Here are the five links, in the order the signal travels them, and what the documentation says about each.

Key Takeaways

• Five links carry the signal: the capsule, the supply that biases it, the converter and its gain, the operating system, and the application. A break at any one looks identical from the outside.
• Two of the three common capsule types need a supply voltage to work at all. A dynamic microphone needs none, which is why it cannot be silenced by a missing power rail.
• The control that fixes a quiet microphone is the one on the input path, and it is very often labelled volume, which is why people raise the wrong slider.
• A browser will not offer a microphone outside a secure context, and a granted permission is not a promise of audio. The W3C specification says so in as many words.
• Speech survives a low sample rate, which is why a thin-sounding call can be working precisely as designed.

The five links a microphone signal has to cross

And the way each one fails:

1. The capsule. Turns air pressure into an electrical signal, and fails by producing a very weak one or none at all.
2. The supply that biases it. Most capsules need a voltage to function; without it the diaphragm still moves and nothing comes out.
3. The converter and its gain. Amplifies the signal and turns it into numbers, and fails by amplifying too little.
4. The operating system. Picks the input device and decides who may hold it, and fails by handing it to something else.
5. The application. For a web page that means the browser, which refuses to ask at all unless several conditions hold first.

None of the five produces a distinctive symptom. Every one produces the same thing at the far end: a flat meter and a silent recording. That is why microphone troubleshooting feels like guesswork, and it is why the quick checks on the fast tests hub can tell you something is wrong long before they can tell you what.

What is actually inside a microphone

A microphone is a transducer: it converts one form of energy into another. The University of Iowa's Electronic Music Studios handout on microphone theory splits them by how they do that conversion, and the split it draws is between dynamic and condenser.

In a moving-coil dynamic microphone, a diaphragm is attached to a coil of wire sitting inside a magnet, and movement induces a current directly. In a condenser microphone, the diaphragm and a fixed backplate form a capacitor; sound changes the distance between them, which changes the capacitance. That change has to be read out by circuitry, and circuitry has to be powered.

Both of the capsule types most people actually own are condensers. An electret carries a permanently charged film, so it needs no polarising voltage of its own, but it still contains a buffer transistor that does. A MEMS capsule is the same principle etched onto silicon, and it is what sits in a laptop lid or a phone. Splitting those two out from the dynamic case gives three practical types, and the third column is the one that decides how a microphone fails.

Capsule type	How it turns sound into electricity	Needs a supply voltage	Where you meet it
MEMS condenser	Silicon diaphragm and backplate form a capacitor on a chip	Yes, from an on-chip charge pump	Laptop lids, phones, earbuds
Electret condenser	Charged film and backplate form a capacitor, read out by a built-in transistor	Yes, 3 V typical on a common part	Headset booms, clip-on mics, budget desk mics
Dynamic, moving coil	Diaphragm moves a coil inside a magnet, inducing a current	No	Stage vocal mics, broadcast and streaming mics

Why a working microphone can be electrically silent

The Iowa handout puts the consequence plainly. "Dynamic microphones require no external power to work", it says, while "condenser microphones contain capacitors, which require electrical power". Two of the three types in that table are therefore only as alive as their supply.

The numbers sit in the manufacturers' own datasheets. Knowles describes the internal charge pump of its SPH0645LM4H-B MEMS microphone as the block that "boosts VDD to a suitable level to bias the MEMS transducer", working from a rail specified between 1.62 V and 3.6 V. Same Sky's CMA-4544PF-W electret capsule is rated for an operating voltage of 3 V typical and 10 V maximum, drawing no more than half a milliamp at 3.0 V into a 2.2 kilohm load.

Cut either supply and the diaphragm still moves. What disappears is the bias that turns that movement into a readable signal, which is the job the Knowles charge pump is doing. A failed bias resistor, a cracked joint on a supply line, or a socket wired for a different pinout all produce a capsule that is mechanically flawless and electrically mute. It is also why a headset can work on a phone and be silent on a laptop: the capsule is fine in both cases, and only one of the two sockets is feeding it.

Gain is not volume, and that is why you are quiet

A capsule's output is tiny. The Same Sky electret is specified at a typical -44 dB relative to one volt per pascal at 1 kHz. That is a ratio of ten to the power of minus 44 over 20, so the capsule delivers about 6.3 millivolts for a one-pascal sound, and one pascal is far louder than speech at a desk. A conversational voice yields a small fraction of that again. The same datasheet records sensitivity dropping about 3 dB when the supply falls from 3.0 V to 2.0 V, which ties the level straight back to the previous link, but there is no gain control inside the capsule itself.

The amplification happens after it, and that is where the confusion starts. Gain is applied to the signal on its way in, before it is digitised. Volume usually names the adjustment on a signal's way out to a speaker. Both are commonly labelled volume, so a recording-level slider is a gain control wearing the other word.

The USB Audio Device Class specification shows why the labels blur. Volume and Automatic Gain Control are both optional controls of a Feature Unit, which the specification describes as a processing unit for the incoming logical channels. Its topology model does not tie such a unit to either side of the path, since units are wired together by connecting their pins according to whatever topology the device needs. A Feature Unit can therefore sit on the record path as readily as the playback path. What separates the two controls is their value domains: Volume takes a decibel figure across a range of roughly plus or minus 128 dB, while Automatic Gain Control is only ever true or false.

So the control to raise for a quiet microphone is the one on the input path, whatever your machine calls it. Browsers then let a page reach the automatic one. The W3C's Media Capture and Streams specification makes it a constrainable property, observing that "Automatic gain control is often desirable on the input signal recorded by the microphone" while letting applications switch it off where they would rather the audio were left alone.

What the operating system decides before any app sees your voice

The operating system owns two decisions, and an application inherits both unless it asks for something else. The first is which device counts as the default input, which is not always the one most recently plugged in. The second is who holds it, and that one is not an application's to make, because an audio input can be claimed exclusively.

The W3C specification acknowledges the second directly: on some operating systems, it notes, "microphone access may get stolen from the User Agent when another application with higher-audio priority gets access to it". The example it gives is an incoming phone call on a mobile operating system.

Losing a device that way is not reported as a failure. In the specification's model the track stays alive and goes quiet, at least until the browser gives up on reacquiring the device and ends it. For a mute the browser itself applies, including the specification's own examples of a hardware mute button and a user "toggling a control in the operating system", it is required to fire mute and unmute events on the track. Where the operating system hands the device to another application, that same reporting is only a recommendation. From a listener's point of view every one of these looks exactly like a microphone that has stopped producing sound.

What a browser requires before it will hand over a microphone

This is the most explicitly specified link in the chain, so it can be stated exactly rather than guessed at.

First, the page has to be in a secure context. The W3C's Secure Contexts specification exists so that features can be enabled only where minimum standards of authentication and confidentiality hold, and it names sensor input as one such category, singling out the camera, the microphone and GPS. Its worked example is blunt: a page served over plain HTTP in a top-level browsing context "is not a secure context, as it was not delivered over an authenticated and encrypted channel". Framing matters too: a secure page embedded in an insecure one is not a secure context either, because its ancestor was not delivered securely. The MediaDevices interface, which the Media Capture and Streams specification extends with getUserMedia, is marked SecureContext in its own interface definition.

Second, permission is scoped to the origin. A user agent "may choose to store this permission for later use by the same origin", so a decision made on one origin says nothing about another. Whether a stored permission covers one device, a class of devices or all of them is left to the browser. A document's permissions policy can block the feature outright too. The default allowlist for the microphone feature is self, so an embedded third-party frame is refused unless the embedding page allows it.

Third, all of that can succeed and still produce silence. A granted permission "is no guarantee that getUserMedia will succeed", the specification says, and "only indicates that the user will not be prompted for permission". Even a live track can be muted, meaning its source is "temporarily unable to provide the track with data". In that state the consumer gets "zero-information-content, which means silence for audio".

Why a call can sound thin and still be working correctly

One more thing makes a working microphone sound wrong, and it sits past the end of the chain rather than inside it: the rate at which a call carries the signal once it has left you.

ITU-T Recommendation G.711, the standard behind digital telephony, is explicit in its second clause: "The nominal value recommended for the sampling rate is 8000 samples per second". That figure comes from the telephone network, and it has not been retired. RFC 7874 puts G.711 on the short list of audio codecs every WebRTC endpoint is required to implement, alongside Opus, so a browser call can still be carried at it.

The consequence is arithmetic. As RFC 6716, the Opus specification, puts it, "the sampling theorem allows a bandwidth as large as half the sampling rate". Eight thousand samples a second therefore carries audio up to 4 kHz, which Opus labels narrowband. Its table of audio bandwidths runs up from there to fullband, 20 kHz of audio at a 48 kHz sample rate, which the RFC describes as the accepted ceiling of human hearing.

A call can drop from 20 kHz of bandwidth to 4 kHz and still carry every word, which is why thinness is a poor diagnostic. The question worth asking is whether you are intelligible, not whether the recording sounds rich. If you want the speaker half of the same chain checked as well, there is a separate sound test for output.

Frequently asked questions

Does a microphone need power to work?

It depends on the capsule. A dynamic microphone generates its own signal by electromagnetic induction and needs no external power at all. Condenser microphones, including the electret capsules in headsets and the MEMS capsules in laptops and phones, contain circuitry that must be powered, so they go silent without a supply even when the diaphragm is undamaged.

Why does my microphone work in one application but not another?

Often because another application is holding the device. The W3C Media Capture and Streams specification notes that on some operating systems microphone access may be taken away from a browser when another application with higher audio priority claims it. The other common cause is that the two applications are pointed at different input devices, because the specification lets a page name the device it wants rather than always taking the system default.

Why is my microphone so quiet even with everything turned up?

Because the control that matters is the one on the input path, and it is easy to raise the wrong one. Gain is applied to the signal arriving from the capsule before it is digitised; playback volume is applied to a signal on its way out to a speaker. Both are commonly labelled volume, so raising the playback slider changes what you hear and nothing about what you send. Look for the recording or input level belonging to the microphone itself.

Why will a website not use my microphone on an insecure page?

Because browsers restrict sensor access to secure contexts. The W3C Secure Contexts specification names the camera, the microphone and GPS as features that should be available only where authentication and confidentiality are assured, and the interface exposing microphone access is marked as requiring a secure context. A page served over plain HTTP does not qualify. A page served over HTTPS does, provided any page framing it was delivered securely too.

I gave permission and the meter still does not move. What now?

A granted permission is not a guarantee of audio. The Media Capture and Streams specification says in terms that permission only indicates the user will not be prompted, and that a live audio track can still be muted, in which case what reaches the application is silence rather than an error. Operating-system muting, a hardware mute switch, and another application holding the device all produce that state, so those are the three worth eliminating.

Sources

• W3C, Media Capture and Streams, Candidate Recommendation Draft, 9 October 2025 - sections 4.3.1.1 (muted tracks, the mute and unmute events, stolen access), 4.3.1.2 (ending a track when reacquisition fails), 4.3.8 (automatic gain control), 9.2 (the MediaDevices interface and device enumeration), 10.1 (getUserMedia and device selection), 13 (permissions), 14 (permissions policy) and Best Practice 2 (stored permissions) - retrieved 13 August 2026, https://www.w3.org/TR/mediacapture-streams/
• W3C, Secure Contexts, Candidate Recommendation Draft, 10 November 2023 - the Abstract, plus sections 1.1 (top-level documents), 1.2 (framed documents) and 4.3 (risks of non-secure contexts) - retrieved 13 August 2026, https://www.w3.org/TR/secure-contexts/
• Knowles, SPH0645LM4H-B datasheet, Rev B - electrical characteristics table and Application Notes hardware description. Knowles publishes no open link to this document; the copy read is the manufacturer's own PDF as mirrored by a distributor - retrieved 13 August 2026, https://cdn-shop.adafruit.com/product-files/3421/i2S+Datasheet.PDF
• Same Sky (formerly CUI Devices), CMA-4544PF-W electret condenser microphone datasheet, dated 11 September 2024 - specifications table, including the sensitivity-reduction row - retrieved 13 August 2026, https://www.sameskydevices.com/product/resource/cma-4544pf-w.pdf
• University of Iowa Electronic Music Studios, Basic Microphone Theory, Fall 2014 course handout, items 2 to 4 - retrieved 13 August 2026, https://theremin.music.uiowa.edu/EMS.Files/Handouts/2014/F.2014/EMS.F2014.MicrophoneTheory.pdf
• USB Implementers Forum, Universal Serial Bus Device Class Definition for Audio Devices, release 1.0, 18 March 1998 - section 3.5 (audio function topology), section 3.5.5 (the Feature Unit) and sections 5.2.2.4.3.2 and 5.2.2.4.3.7 (Volume and Automatic Gain Controls) - retrieved 13 August 2026, https://www.usb.org/sites/default/files/audio10.pdf
• ITU-T, Recommendation G.711: Pulse code modulation (PCM) of voice frequencies - clause 2, sampling rate - retrieved 13 August 2026, https://www.itu.int/rec/T-REC-G.711/
• IETF, RFC 6716: Definition of the Opus Audio Codec, September 2012 - section 2, Table 1 and its footnote, audio bandwidth against sample rate - retrieved 13 August 2026, https://www.rfc-editor.org/rfc/rfc6716.txt
• IETF, RFC 7874: WebRTC Audio Codec and Processing Requirements, May 2016 - section 3, the codecs a WebRTC endpoint is required to implement - retrieved 13 August 2026, https://www.rfc-editor.org/rfc/rfc7874.txt