DEV Community: Syed Salman

Building a microphone test with getUserMedia and Web Audio: levels, noise floor and honest errors

Syed Salman — Fri, 30 Oct 2026 09:31:40 +0000

"Is my mic working?" gets searched constantly, right before a call, an interview or an online exam. A browser can answer it properly: it can open the microphone, measure the signal, and tell you why it couldn't open it. Here's how I put together a microphone test, and the details that turned out to matter.

The audio graph: analyse, but don't play back

getUserMedia ──> MediaStreamSource ──> AnalyserNode      (never connected to the speakers)
             └─> MediaRecorder (5 s clip) ──> <audio> ──> speakers

The live input goes to an AnalyserNode and stops there. If you connect it to ctx.destination, laptop speakers feed straight back into the laptop mic and you get a howl. To let people hear themselves, record a short clip with MediaRecorder and play it back afterwards.

const stream = await navigator.mediaDevices.getUserMedia({
  audio: { echoCancellation: true, noiseSuppression: true, autoGainControl: true }
});
const ctx = new AudioContext();
const analyser = ctx.createAnalyser();
analyser.fftSize = 2048;
ctx.createMediaStreamSource(stream).connect(analyser);   // no .connect(ctx.destination)

Measure level as RMS in dBFS

getFloatTimeDomainData gives samples between -1 and 1. The root mean square of a frame is a good "how loud" number, and the largest absolute sample is the peak:

const buf = new Float32Array(analyser.fftSize);
const toDb = x => x > 1e-7 ? 20 * Math.log10(x) : -140;

function measure() {
  analyser.getFloatTimeDomainData(buf);
  let sum = 0, peak = 0;
  for (const v of buf) {
    sum += v * v;
    peak = Math.max(peak, Math.abs(v));
  }
  return {
    rmsDb: toDb(Math.sqrt(sum / buf.length)),
    peakDb: toDb(peak),
    clipped: peak >= 0.999      // at (or effectively at) full scale
  };
}

0 dBFS is the digital maximum, so readings are negative. Be clear in the UI that this is relative to the converter. It isn't calibrated sound pressure, and a web page can't tell you "65 dB SPL".

Meters feel right with an instant attack and a slow release (about 20 dB per second), plus a peak marker that holds for 1.5 s before falling. Count clipping events instead of flashing on every clipped sample, or one loud word reads as dozens of clips.

Noise floor: the 10th percentile, not the average

People want to know "is my room noisy?" The average level mixes their voice in with the background. What you want is the level in the quiet moments between sounds, so keep about 8 seconds of RMS readings and take a low percentile:

function noiseFloor(history /* recent RMS dB values */) {
  const vals = history.slice().sort((a, b) => a - b);
  return vals[Math.floor(vals.length * 0.1)];
}

Then translate it into words. Below about -70 dBFS is very quiet, -55 is a quiet room, around -42 is fan or traffic noise, and above that is noisy. One trap: if auto gain control is on, the browser turns the background up during silence, so mention that next to a noisy result.

Report what the browser actually applied

You can ask for echo cancellation, noise suppression and auto gain, but the browser decides. track.getSettings() tells you what you got:

const s = stream.getAudioTracks()[0].getSettings();
// s.echoCancellation, s.noiseSuppression, s.autoGainControl, s.sampleRate, s.channelCount

Showing "noise suppression: on, browser overrode your choice" explains a lot of "my mic sounds weird on calls" reports. Noise suppression can also gate the silence to digital zero, which shows up as a perfect -∞ noise floor. That's worth saying in plain words rather than reporting "excellent".

Errors: "blocked" doesn't mean "broken"

Half the value of a mic test is what it says when the mic doesn't open. getUserMedia rejects with a named DOMException, and each name has a different fix:

Error	What it usually means
`NotAllowedError`	Permission denied by the browser or the OS. The mic may be fine.
`NotFoundError`	No input device visible: unplugged, disabled, or a headset mute switch.
`NotReadableError`	The device exists but another app (Zoom, Teams, Discord) has it.
`OverconstrainedError`	The chosen device can't satisfy the constraints you asked for.

Older browsers used PermissionDeniedError, DevicesNotFoundError and TrackStartError, so map those to the same messages. For NotAllowedError, point to the OS setting too (Windows Privacy > Microphone, macOS Privacy & Security > Microphone), because a site-level "Allow" doesn't help when the OS is blocking the browser.

And getUserMedia only exists on secure (https) pages, so check for navigator.mediaDevices first and say "open this over https" instead of throwing.

Let go of the mic

Ask for the microphone only when the user presses Start, never on page load. Release it (stop every track) on Stop, when the device or settings change, on pagehide, and when the tab is hidden. Nobody wants a recording indicator still lit after they've left your page. Keep recordings as object URLs in the tab; there's no reason to upload anything.

stream.getTracks().forEach(t => t.stop());

I built the microphone test linked above. Drafted with AI assistance; the code is adapted from the production tool.

Measuring a monitor's refresh rate with requestAnimationFrame (and why the average lies)

Syed Salman — Thu, 29 Oct 2026 23:40:58 +0000

"Is my 144 Hz monitor actually running at 144?" is a question people search for every day, and the browser can answer it reasonably well. requestAnimationFrame fires once per frame the browser presents, with a high-resolution timestamp. The gap between two callbacks is the frame time, and 1000 / frameTime is the refresh rate.

That's the whole idea. Making it give a trustworthy number took a few more decisions, which I made while building a refresh rate test.

The basic loop

const WINDOW = 120;      // frames the rate is measured over
const AWAY_MS = 500;     // a gap this long is the tab being away, not a frame
let intervals = [], last = 0;

function frame(now) {
  requestAnimationFrame(frame);
  if (last) {
    const dt = now - last;
    if (dt > 0 && dt < AWAY_MS) {
      intervals.push(dt);
      if (intervals.length > WINDOW) intervals.shift();
    }
  }
  last = now;
}
requestAnimationFrame(frame);

A rolling window of 120 frames means the reading follows the display live instead of averaging over everything since page load.

Use the median, not the mean

One slow frame, from garbage collection or another tab waking up, drags an average well below the true rate. On a 60 Hz screen a single 50 ms hiccup in 120 frames pulls the mean down to about 59 Hz. The median ignores it:

function medianOf(values) {
  const s = values.slice().sort((a, b) => a - b);
  const m = s.length >> 1;
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
}

const hz = 1000 / medianOf(intervals);

A refresh rate should be one of a handful of fixed numbers, so an outlier-resistant statistic is the right tool. I use the same idea for jitter: the median absolute deviation from the median frame time, not the standard deviation.

Snap to a known rate, but only when it's close

A 144 Hz panel measures as 143.9 or 144.1. Showing "143.9 Hz" makes people think something is wrong. So the big number snaps to a common rate, but only within a tolerance, and the raw value is always shown underneath:

const COMMON = [30, 48, 50, 60, 75, 90, 100, 120, 144, 165, 180, 240, 360];

function snap(rate) {
  for (const c of COMMON) {
    // 1.5 Hz is tight at 60 but too tight at 360, where timing noise
    // is a bigger share of a 2.8 ms frame
    if (Math.abs(c - rate) <= Math.max(1.5, c * 0.025)) return c;
  }
  return null;   // unusual panel: report it as itself
}

The tolerance scales with the rate. A fixed ±1.5 Hz works at 60 Hz, where a frame is 16.7 ms, but at 360 Hz a frame is only 2.8 ms and normal timer noise moves the reading more than that.

Don't call the first frames "dropped"

Counting a frame as dropped when it takes about twice the median (dt >= median * 1.8) is a useful signal. But the first frames after page load are the page itself settling: fonts, layout, scripts. Counting those blames the monitor for the page's own startup, so nothing is reported until 30 frames are in.

Background tabs and monitor changes

Browsers throttle or stop requestAnimationFrame in hidden tabs. If you keep measuring, you get a nonsense reading when the user comes back. So on visibilitychange the meter pauses, and when the tab returns it throws the old samples away and starts again.

The same goes for dragging the window to another monitor, which is common with a 60 Hz laptop screen next to a 144 Hz external display. I keep a cheap signature of the current screen and reset when it changes:

const signature = () =>
  [screen.width, screen.height, devicePixelRatio, screen.availLeft || 0, screen.availTop || 0].join('|');

Be honest about what it measures

This is the rate the browser presents frames at. That's usually the monitor's rate, but not always:

Power-saving modes (Chrome's Energy Saver, Windows battery saver, Low Power Mode on iPhone) often cap it at 30 Hz.
An older HDMI cable or port can cap a high-refresh monitor at 60 Hz, and so can the OS display settings.
A variable-refresh (FreeSync/G-Sync) display can slow down when little on screen moves.

So the page reacts to the result. At around 30 Hz it suggests checking power saving. At 60 Hz it suggests checking the OS setting, the cable and the browser. Above 60 it confirms the high refresh, with the VRR caveat. A tool that shows "60" and leaves you to guess the reason isn't very useful.

I built the refresh rate test linked above. It runs entirely in the browser. Drafted with AI assistance; the code is adapted from the production tool.

Verifying a JWT in the browser with Web Crypto: four things that bite

Syed Salman — Thu, 29 Oct 2026 20:17:19 +0000

Web Crypto can verify every common JWT signature (HS256, RS256, PS256, ES256 and their bigger siblings) with no library at all. The API call itself is one line. The bugs live around it. Here are the four I had to get right while building a JWT signature verifier.

1. Never take the algorithm from the token

A JWT header says which algorithm signed it:

{ "alg": "RS256", "typ": "JWT" }

It's tempting to read alg and verify with whatever it says. Don't. The header is attacker-controlled, and that opens two classic holes:

alg: none. The token claims it has no signature, and a naive verifier accepts it.
RS256 to HS256 confusion. The attacker re-signs the token with HMAC, using your RSA public key as the HMAC secret. A verifier that follows the header and feeds that same public key into HMAC will accept it.

The fix is to have the caller choose the algorithm and ignore the header's choice:

const ALGS = {
  HS256: { name: 'HMAC', hash: 'SHA-256' },
  RS256: { name: 'RSASSA-PKCS1-v1_5', hash: 'SHA-256' },
  PS256: { name: 'RSA-PSS', hash: 'SHA-256', saltLength: 32 },
  ES256: { name: 'ECDSA', hash: 'SHA-256', crv: 'P-256' },
  // ...384 and 512 variants follow the same pattern
};

// `alg` comes from your config or the user's choice, never from decoded.header.alg
async function verify(decoded, key, alg) {
  const info = ALGS[alg];
  if (!info) throw new Error(`Unsupported algorithm "${alg}"`);
  // ...
}

none isn't in the table, so it can't get through. In the tool, the dropdown starts on the header's value because that's almost always right. But the value passed to verify() is the one in the dropdown, and if the header disagrees, the page says so.

2. ECDSA signatures in JOSE are raw r||s, not DER

This one produces the worst kind of bug: the right key and an untouched token, but the result is "not verified".

JOSE (RFC 7518) encodes an ECDSA signature as the two integers r and s, each padded to the curve size and joined together: 64 bytes for P-256. OpenSSL and many server libraries emit a DER SEQUENCE of two INTEGERs instead. Web Crypto's verify() wants the raw form. So if a signature starts with 0x30 and isn't exactly 2 * size bytes, convert it:

function derToRaw(der, size) {
  let i = 0;
  if (der[i++] !== 0x30) throw new Error('Not a DER SEQUENCE');
  let len = der[i++];
  if (len & 0x80) i += len & 0x7f;          // long-form length

  const readInt = () => {
    if (der[i++] !== 0x02) throw new Error('Expected a DER INTEGER');
    const l = der[i++];
    let v = der.slice(i, i + l);
    i += l;
    while (v.length && v[0] === 0) v = v.slice(1);   // strip sign padding
    const out = new Uint8Array(size);
    out.set(v, size - v.length);                      // left-pad to curve size
    return out;
  };

  const r = readInt(), s = readInt();
  const raw = new Uint8Array(size * 2);
  raw.set(r, 0);
  raw.set(s, size);
  return raw;
}

const size = { 'P-256': 32, 'P-384': 48, 'P-521': 66 }[info.crv];
if (sig.length !== size * 2 && sig[0] === 0x30) sig = derToRaw(sig, size);

Note P-521 is 66 bytes per integer, not 65. 521 bits rounds up to 66 bytes.

3. The actual verify call

With the algorithm pinned and the signature in the right shape, the check itself is short. The signed data is the ASCII header.payload string, exactly as it appeared in the token:

const params =
  info.name === 'HMAC'    ? { name: 'HMAC' } :
  info.name === 'ECDSA'   ? { name: 'ECDSA', hash: info.hash } :
  info.name === 'RSA-PSS' ? { name: 'RSA-PSS', saltLength: info.saltLength } :
                            { name: info.name };

const ok = await crypto.subtle.verify(
  params, key, sig, new TextEncoder().encode(decoded.signingInput)
);

Wrap it in a try. A key imported for the wrong algorithm throws instead of returning false, and you want to report that as "this key can't check this signature", not as a crash.

Also reject private keys outright. Verification only needs the public half. If someone pastes a PEM containing PRIVATE KEY, or a JWK with a d member, the kind thing to do is stop and tell them not to paste private keys into web pages.

4. Check the HMAC secret length, and say what a pass doesn't mean

RFC 7518 requires an HMAC key at least as long as the hash: 256 bits for HS256. Anyone holding a single token signed with a short secret can brute-force it offline, then mint their own tokens. If the secret is shorter than that, say so even when the signature verifies.

And a valid signature only proves the token is authentic and unmodified. It doesn't prove it hasn't expired (exp), that it was meant for you (aud), or that the key you checked against really belongs to the issuer. Those are separate checks, and a verifier UI should say so next to the green tick. I put the claim checks in a separate JWT security analyzer so the two answers don't get mixed up.

I built the verifier and analyzer linked above. Everything above runs in the browser and the token never leaves the tab. Drafted with AI assistance; the code is adapted from the production tool.

How to run a user's regex without letting it freeze the browser tab

Syed Salman — Thu, 29 Oct 2026 20:00:56 +0000

If your page lets people type a regular expression and run it, one bad pattern can lock the whole tab. JavaScript's RegExp engine backtracks, so a pattern like this one

/^(a+)+$/

against "aaaaaaaaaaaaaaaaaaaaaaaaaaaa!" takes exponential time. The browser's main thread is busy the whole time, so clicks, scrolling and even the "Stop" button stop responding. There is no way to interrupt a running RegExp.exec() from the same thread.

I ran into this while building an online regex tester. The fix turned out to be small: run the match in a Web Worker and kill the worker if it takes too long.

1. Put the matcher in a worker built from a Blob

You don't need a separate file. Build the worker source as a string and load it through a Blob URL:

const WORKER_SOURCE = `
self.onmessage = (e) => {
  const { pattern, flags, text } = e.data;
  try {
    const re = new RegExp(pattern, flags.includes('g') ? flags : flags + 'g');
    const matches = [];
    let m, count = 0;
    while ((m = re.exec(text)) !== null && count < 5000) {
      matches.push({ index: m.index, match: m[0], groups: m.slice(1) });
      count++;
      if (m[0].length === 0) re.lastIndex++; // avoid an infinite loop on empty matches
    }
    self.postMessage({ ok: true, matches, truncated: count >= 5000 });
  } catch (err) {
    self.postMessage({ ok: false, error: err.message });
  }
};`;

Two details matter here:

Empty matches. A pattern such as /a*/g can match an empty string. Without the lastIndex++, exec() returns the same empty match forever.
A match cap. Even a fast pattern can return millions of matches. Capping at 5,000 keeps the postMessage payload sane.

2. Give it a time budget and terminate on timeout

worker.terminate() is the one thing that can stop a runaway regex, because it kills the worker's thread no matter what it is doing.

const TIME_BUDGET_MS = 1500;

function runRegex(pattern, flags, text) {
  return new Promise((resolve) => {
    const url = URL.createObjectURL(new Blob([WORKER_SOURCE], { type: 'application/javascript' }));
    const worker = new Worker(url);
    let settled = false;

    const finish = (result) => {
      if (settled) return;
      settled = true;
      clearTimeout(timer);
      worker.terminate();
      URL.revokeObjectURL(url);
      resolve(result);
    };

    const timer = setTimeout(
      () => finish({ ok: false, timedOut: true }),
      TIME_BUDGET_MS
    );

    worker.onmessage = (e) => finish(e.data);
    worker.onerror = (e) => finish({ ok: false, error: e.message });
    worker.postMessage({ pattern, flags, text });
  });
}

The settled flag is there because the timeout and the worker's reply can race. Whichever fires first wins, and the other is ignored.

A new worker per run sounds wasteful, but creating one takes a few milliseconds. It also means a terminated worker never leaves bad state behind for the next run.

3. Validate input before you start the worker

Cheap checks up front save a worker round trip and give clearer errors:

if (pattern.length > 500) return error('Pattern is too long');
if (text.length > 200_000) return error('Test text is too long');
if (!/^[gimsuy]*$/.test(flags)) return error('Flags may only contain g, i, m, s, u, y');

4. Be honest about what a timeout means

When the budget runs out, the UI says the pattern may be vulnerable to catastrophic backtracking on this input. A timeout is not proof that a pattern is unsafe, and finishing in time is not proof that it is safe. A different input could still blow up. If you need a real guarantee for server-side code, use a non-backtracking engine such as RE2. Or check for nested quantifiers like (a+)+ and (a|a)*, which are the usual culprits.

Try it

You can paste ^(a+)+$ and a long run of as followed by ! into the regex tester and watch it time out after 1.5 s while the page stays responsive. The same pattern in a plain <script> would hang the tab.

I built the regex tester linked above. Drafted with AI assistance; the code is taken from the production tool.