DeskTest.net
GitHub

Device Selection Check Guide

A reference for the DeskTest.net Device Selection Check: the one-page tool that confirms a call will use the right microphone, speaker, and camera - not a virtual camera, and not a device another app is holding - and that the mic is not turned up so hot that it clips. This guide covers what each step checks, how to read the verdict, and what to do about each result.

Open the Device Selection Check →

What does the Device Selection Check check?

The tool drives standard browser APIs: a single getUserMedia grant to unlock device names, navigator.mediaDevices.enumerateDevices() to list them, short deviceId-pinned getUserMedia probes to test for a lock, and the Web Audio API to read the raw microphone waveform. No plugin, no extension, no upload. It runs three steps in order:

  1. Devices are visible. Behind a Start button (browsers require a click before granting the camera or mic), it requests one combined grant. Browsers hide device labels until you allow access once; with the grant in hand it enumerates every audio input, audio output, and video input by name and marks the system default of each kind. Camera names that match known virtual-capture software (OBS, Snap, ManyCam, and similar) are flagged likely virtual.
  2. Devices are free. Each microphone and camera is briefly re-opened by its exact device ID. If the browser returns NotReadableError or TrackStartError, another application already holds that device, and it is marked in use by another app. Every probe stream is stopped the instant it opens.
  3. Microphone level is healthy. You pick the mic you will use and speak for a few seconds. The tool opens it with automatic gain control, echo cancellation, and noise suppression turned off - AGC off is essential, or the browser would quietly ride the level and hide a hot input - then feeds the signal to a Web Audio AnalyserNode and reads getFloatTimeDomainData. It counts samples that hit the ceiling (0.99 or above), watches for flat-topped runs, and computes the crest factor. A clipping input warns mic level too hot.

Why not just use the webcam or mic test?

The Webcam Test shows a preview and the Microphone Test shows a level meter, but neither answers the questions that actually derail calls: am I about to send a virtual camera by mistake, is a background app already holding my headset, and is my mic cranked so high it distorts? The System Info page lists devices but statically - it does not probe whether they are free or measure the signal. This tool folds those three gaps into one pass.

When should I run this?

Reading the results

Each step shows a status badge: Pending (gray), Running (yellow), Pass (green), Warn (yellow), or Fail (red). On a warn or fail, the row expands with the device list or measurement and a numbered checklist.

Most notes here are warnings, not failures, because they are often intentional: a virtual camera is fine if you meant to send it, and a held device is fine if the app holding it is the very call you are joining. A hard fail is reserved for a step that could not run at all - no devices, no permission, or a browser without the Media Devices API.

The verdict panel at the top summarizes overall readiness with a likely cause and a recommended next step. Copy Diagnostic Report copies a plain-text report - device names, which are locked, and the mic peak, crest factor, and clipped-sample count - for a ticket. Send to your IT opens the same text in a pre-filled email.

Understanding mic clipping and headroom

Digital audio has a hard ceiling. On the tool's 0-to-1 scale, 1.0 is the loudest the mic can represent; in decibels that ceiling is 0 dBFS (decibels relative to full scale, always zero or negative). When your input gain is too high, the loudest moments of your voice slam into that ceiling and get flat-topped - the rounded shape of the waveform is sheared off into a flat line. Listeners hear that as harsh, crackly, or crunchy audio, and no amount of far-end volume fixes it, because the detail is already gone.

The tool reports three numbers:

NumberWhat it meansWhat you want
Peak levelThe single loudest sample, on the 0-to-1 scale and in dBFS.Below about 0.7 (roughly -3 dBFS). Some headroom under the ceiling.
Crest factorHow far the peak sits above the average level, in dB. Clipping and heavy compression flatten this.Roughly 12 to 20 dB for natural speech.
Clipped samples / flat-topped runsHow many samples touched the ceiling, and how many sustained runs of them occurred.Zero flat-topped runs.

A flat-topped run is the real red flag: a single sample brushing the ceiling can be a legitimate transient, but several in a row means the signal is genuinely clipping. The usual culprit on Windows is Microphone Boost (a per-device +20 dB or +30 dB gain), and on any platform an input volume set near maximum or a USB mic with its gain knob turned up. The fix is always the same: lower the input until normal speech peaks a few dB below the ceiling with no flat runs.

Note: a few browsers ignore the request to disable automatic gain control. When that happens the tool says so in the mic panel and treats the reading conservatively, because AGC can mask a hot input by pulling it down before you ever see it.

Common results and fixes

Likely virtual camera present (warning)

A camera name matched known virtual-capture software (OBS Virtual Camera, Snap Camera, ManyCam, and similar). This is only a heads-up - it is exactly right if you are presenting through OBS. But if you meant your real webcam, open your call app's video settings and pick the physical camera by name, because a virtual camera can quietly become the system default.

Device in use by another app (warning)

A microphone or camera returned NotReadableError when probed, meaning something else has it open. If that something is the call you are about to join, ignore it. If it should be free, close other conferencing and softphone apps completely - check the system tray, not just the window - since many webcams and headsets cannot be shared by two apps at once. If a device stays stuck, unplug and replug it, or sign out and back in to clear a wedged process, then rerun.

Mic level too hot / clipping (warning)

The waveform is flat-topping. Lower the input: on Windows, Settings then System then Sound then your input device, drop the Volume, and under Device Properties turn off Microphone Boost. On macOS, System Settings then Sound then Input, lower the Input volume. On a USB mic or audio interface, turn down the physical gain knob and back off from the mic slightly. Rerun and aim for a peak a few dB below the ceiling with no flat-topped runs.

No signal during the level check (warning)

The mic opened but stayed near silence, so headroom could not be judged. Check for a hardware mute switch, confirm you selected the mic you actually speak into, raise its input level in the OS, then rerun and speak at your normal call volume for the full few seconds.

Access not granted (warning)

Without one permission grant, browsers hide device names, so nothing can be told apart or measured. Allow the camera or microphone for this site: click the permission icon in the address bar (Chrome, Edge, Firefox) and set it to Allow, then reload. On Safari, use Settings then Websites then Camera / Microphone. Confirm the OS also allows the browser: Windows Settings then Privacy then Camera / Microphone, or macOS System Settings then Privacy and Security.

No devices, or API unavailable (failure)

If no microphone or camera is detected, plug one in and rerun. If the tool says the Media Devices API is unavailable, the page is likely on plain http:// (the API needs HTTPS or localhost) or the browser is too old - open https://desktest.net/device-sanity/ in a current desktop browser.

Privacy: what stays local

Your microphone and camera never leave this device. The one permission grant is used only to read device names; the mic feeds only the on-screen level meter through the Web Audio API, and nothing is ever recorded, saved, or transmitted. Every track - the grant, each in-use probe, and the level-check stream - is stopped the moment it is done, and the audio context is closed, on completion, on reset, and when you leave the page, so the device indicators turn off. The report contains only device names and the mic level seen. It never contains any audio or video. View source to verify.

For IT admins

Device access is governed at two layers - per-site browser permission and the OS privacy switch - and both must allow the browser before this tool (or a call app) can enumerate names.

Chrome / Edge. Push via GPO, Intune, or Jamf: VideoCaptureAllowed and AudioCaptureAllowed (global booleans) plus VideoCaptureAllowedUrls and AudioCaptureAllowedUrls (URL patterns that bypass the prompt, e.g. https://desktest.net).

Firefox. Push policies.json with Permissions.Camera and Permissions.Microphone: an Allow array of origins, plus BlockNewRequests: true.

Windows. Camera and microphone are gated under Settings then Privacy; push via the Camera and Microphone Policy CSPs (LetAppsAccessCamera, LetAppsAccessMicrophone). Windows feature updates sometimes reset these, so check first if a device dies right after an update. Microphone Boost lives under the legacy Sound control panel per device - a common cause of clipping the tool will flag.

Virtual devices. If your image ships OBS, a virtual audio cable, or Snap Camera, expect them to appear here and to sometimes become the default. Consider setting the intended physical device as the OS default in your build so calls do not pick up a virtual device by accident.