Bluetooth microphone test — level, sample rate and quality

A microphone test has to answer three things: whether signal is arriving at all, whether the level is usable, and at what quality. The panel above answers all three, and it adds the one readout most mic tests leave out: the sample rate of the input you picked. That number is where a Bluetooth headset gives itself away.

What the test measures

Press start, allow the microphone, and the panel fills in five separate things. None of them is a guess; each is read from the live audio track your browser opened.

• Input device. The picker lists every microphone the browser can see. Device names stay blank until you have granted permission once, so the list only labels itself properly after your first start. Anything whose name looks like a headset is tagged looks Bluetooth.
• Level, in dBFS. A rolling one-second average of the signal, drawn as a bar and printed as a number. This is the readout the verdict line is based on.
• Peak, held. The loudest single sample recently seen, held and then bled off at about 24 dB per second so that a spike is readable instead of a flash. The bar flags itself when a peak passes −1 dBFS.
• Sample rate and channel count. Taken from the track settings, with the audio context rate as a fallback. Anything at or below 24 kHz is marked narrowband.
• Five seconds, recorded and played back. The most honest test there is, because your ears do the judging. You can download the result as a WAV if you want to keep it.

What the test deliberately does not do is push your microphone back out through your speakers while it runs. That is a feedback loop waiting to happen on a laptop, and it is a different job anyway: the live mic monitor handles pass-through, with a gain cap and a howl guard built in.

Reading the level

dBFS means decibels relative to digital full scale. Zero is the ceiling and every real signal is a negative number. Speech that averages around −20 dBFS with peaks near −6 dBFS is in good shape. These are the bands the verdict uses:

A quiet reading is usually distance, not a fault. A hand-held phone at 15 cm and the same phone on a table two metres away are not the same microphone, and no setting closes that gap.

The sample rate is where a Bluetooth headset confesses

Run the test once with your laptop or phone microphone, then run it again with a Bluetooth headset picked as the input. Watch the sample rate. It typically collapses from 44.1 or 48 kHz to 16 kHz or 8 kHz, and the channel count drops to 1.

That is not a browser bug. A Bluetooth link carries one profile at a time. Stereo music runs over A2DP, which is output-only. The moment something asks for the headset's microphone, the link has to switch to the Hands-Free Profile, and HFP is a telephone profile: mono, sampled at 8 kHz in narrowband mode, which throws away everything above roughly 4 kHz. When both ends negotiate wideband speech the rate rises to 16 kHz and the ceiling moves up to roughly 8 kHz, still far short of what a music link carries. Either way a headset microphone sounds like a phone call. The full picture is in the guide on the quality drop when Bluetooth switches to HFP.

Why phone microphone in, Bluetooth speaker out sounds better

Once you have watched the sample rate collapse, the design of a mic-to-speaker setup stops being a matter of opinion. If the phone's own microphone is the input and the Bluetooth device is only ever an output, there is normally no reason for the link to switch profiles. It stays on A2DP at full bandwidth in the ordinary case, and the microphone you are using is a wideband one sitting in your hand rather than a narrowband one clipped to your ear. The usual exception is a car head unit that is already connected for hands-free: iOS can still put the session on HFP in a configuration like that, and the sample rate readout is where you would see it.

That is the whole architecture of the Bluetooth mic app for iPhone this site is built around: the phone is the microphone, the Bluetooth speaker is the output, and nothing asks the speaker for an input, which is what normally keeps the link on A2DP. If you want to see the routing steps written out, the guide on connecting an iPhone microphone to a Bluetooth speaker covers what happens in iOS Settings. Pairing is an iOS job, not something an app can do, because iOS exposes no public API for it.

What this arrangement does not fix is delay. Bandwidth and latency are separate problems, and staying on A2DP does nothing about the second one. Measure yours with the Bluetooth latency test, which plays a chirp and listens for it coming back, and read the explanation of where Bluetooth microphone delay comes from before you go looking for a setting that removes it. There isn't one.

What this test cannot tell you

This is a browser measurement, and there are four things it genuinely cannot see. Knowing them is the difference between a number and an answer.

1. The reported rate is what the operating system hands over, not what the radio is doing. Safari in particular reports almost nothing useful from track settings, so the page falls back to the audio context rate, which can read a confident 48 kHz while the actual capture is narrowband, upsampled somewhere between the headset and the tab. The playback is the tiebreaker. If the five-second recording sounds like a phone call, it is one, whatever the readout says.
2. On an iPhone or iPad, you cannot choose the input from a web page. iOS picks the route itself, so the device picker will be short or empty there. To watch the profile switch happen, run this on a desktop browser. On the phone, just connect the headset and listen to the difference in the recording.
3. dBFS is not loudness in the room. It is a level relative to digital full scale, so a sensitive microphone and a dull one reading the same number are not hearing the same voice. This is a signal-chain check, not a sound level meter, and it says nothing about how loud you will be once you are actually amplified.
4. It measures nothing about delay, and nothing about the output side. Round-trip timing belongs to the latency test. If the problem is buzzing, a dead channel or a speaker that will not reach low frequencies, that is the Bluetooth speaker test with its channel checks and its 20 Hz to 20 kHz sweep.

The browser also asks for echo cancellation, noise suppression and automatic gain control to be switched off, so you hear the raw input. It asks. Some drivers and some operating systems process the signal anyway, and no web page can override that.

The five-second recording stays in this tab

The recorder writes a WAV in memory and hands the tab a local link to it. Nothing is uploaded, nothing is sent anywhere, and closing the tab discards it. The download button exists so you can keep a file and compare it against another one later.

What to do about a bad result

Match the verdict to the fix rather than changing settings at random.

• No signal. Check the picker first, then close whatever else has the microphone open. Video-call apps hold the input even when they are only sitting in the background.
• Too quiet. Get closer before you touch a gain control. Then raise the input level in your system sound settings, not in the browser.
• Clipping. Back off, or lower the input level. Peaks that hit full scale are gone for good.
• Narrowband. Stop using the headset as the microphone. Use the phone or laptop microphone as the input and send the audio out over Bluetooth instead. If the sound has to be right and the room is difficult, a cable still beats every wireless option, which the comparison of wired against Bluetooth microphones works through honestly.

Once the level and the bandwidth are both sane, the interesting part is what you do with the signal. The voice preset page runs all eight of the app's presets live with their real frequency-response curves, so you can hear what a lowpass at 480 Hz or a bandpass at 1.8 kHz actually does to a voice. If you are setting up for an event rather than a desk, work through the party microphone checklist before the guests arrive rather than during.