Meeting Readiness Guide

A reference for the DeskTest.net Meeting Readiness check. One click - and one camera and microphone prompt - runs six quick A/V and network checks in your browser and rolls them into a single go/no-go with a readiness score you can act on or hand to IT. This guide explains what each check looks at, what it honestly cannot know, how the score is built, and how to read and share the result.

Open the readiness check ->

What the check does

Meeting Readiness answers one question: are you ready for your video call right now? It asks the browser for your camera and microphone once, then runs six checks off that single grant - camera, microphone, speakers, echo risk, device selection, and a call-grade network probe - and gathers them into one dashboard with an overall readiness score in a ring. It is a fast, plain-language go/no-go a non-technical user can run in about fifteen seconds, not a deep diagnostic. Each check gets a tile you can expand for the detail, and the whole run can be copied or emailed to your IT team.

You will be asked to speak for a few seconds (so the mic level can be measured) and you will hear a short test tone and a chirp (for the speaker and echo checks), so set your volume to a normal level before you start. When the run finishes, your camera and microphone are released immediately.

The six checks

Every run performs the same six checks, in order. Each is graded Ready (green), Attention (amber, worth a look) or Problem (red, will likely affect the call).

1. Camera

Attaches your camera to a preview, then measures the frame rate the pipeline actually delivers (counting real presented frames, not the rate the camera advertises), and builds a luminance histogram to grade your exposure and detect a backlit subject against a bright window. Smooth frame rate, good exposure, and no backlight earn Ready. Underexposed, overexposed, backlit, or a below-smooth frame rate earn Attention. No frames delivered at all is a Problem.

2. Microphone

Opens your mic with automatic gain control turned off (so a hot input cannot hide) and watches the raw waveform while you speak, measuring the peak level and counting clipped, flat-topped samples. A clean signal with headroom is Ready. A level that is clipping, dangerously hot, or so quiet that no speech was detected is Attention. No microphone at all is a Problem.

3. Speakers

Plays a short 440 Hz test tone through your output, left channel then right, and confirms the audio pipeline produced a signal. This is the one check with an honest limit worth stating plainly: the browser can prove sound was generated, but it cannot confirm the sound reached your ears - only you can. Where you are on speakers (not headphones), the Echo check below independently confirms the speaker physically produced sound, because your mic hears the chirp.

4. Echo risk

Plays a short chirp through your speakers and listens for it coming back into your microphone, then cross-correlates the two to measure how strongly the speaker feeds the mic - the "you're echoing" speakerphone problem. No return is Ready (or expected, on headphones). A clear return is Attention (use a headset). A return nearly as loud as the source is a Problem (feedback risk). Echo cancellation is deliberately requested off so a real echo is not hidden; your call app should keep its own echo cancellation on.

5. Device selection

Lists your cameras, microphones, and outputs by name, shows which are active, and flags a camera that looks like virtual capture software (OBS, Snap, and similar) so you do not accidentally send a virtual camera. A real active camera and mic earn Ready; a virtual active camera, an installed virtual camera, or a missing microphone earns Attention.

6. Network for calls

Confirms you can reach the internet, then measures round-trip latency and jitter to edge.desktest.net and opens a WebSocket to confirm real-time upgrades are allowed. This is the call-grade network view - latency, jitter, and lost probes - not a download-speed headline. Low latency, low jitter, no lost probes, and a working WebSocket earn Ready. High jitter, high latency, lost probes, or blocked WebSockets earn Attention. No reachability at all is a Problem.

What it cannot determine

The trust in this tool comes from being honest about its limits. It deliberately does not claim to know:

• Whether you actually heard the speaker - it can only prove the audio pipeline produced sound.
• Which camera, microphone, or speaker your meeting app will finally use - set that in the app itself.
• How your meeting app will re-encode or crop the camera stream.
• Echo introduced by the far end or the meeting server.
• The real media-path quality to your meeting provider - the network check measures the path to the desktest edge, which is a strong proxy but not the same route.
• Whether a background app is quietly holding a device - probing that would disrupt the very devices being measured, so it is not asserted.

These limits are printed in the report too, so whoever receives it knows exactly what was and was not measured.

How the readiness score works

Each check is scored Ready, Attention, or Problem, and each carries a weight so the checks that matter most to being seen and heard count for more - Microphone and Network weigh the most, then Camera and Echo, while Speakers and Device selection weigh a little less. A Ready result counts in full, an Attention counts a little over half, and a Problem counts zero. The weighted results combine into the single percentage in the ring, labeled Ready.

Treat the ring as a quick go/no-go, not a precise benchmark. A high score with everything green reads as "you're ready" (framed for your specific call - see below); the middle range means a few things to fix first; a low score, or any hard Problem, means something is likely to affect the call. The summary lists the checks that need attention, in priority order, so you know which tile to open first.

Reading the result and handing it to IT

Every check appears as a tile you can expand for the specifics - the exact values it read, an honest note about what it could not know, and, when something needs attention, a plain-language "What to do." Below the dashboard are three buttons:

• Copy report copies a plain-text version of the whole run - the score, every check with its readings and notes, the "what to do" fixes, and the list of things the check cannot determine - ready to paste into a ticket or email.
• Send to your IT opens a pre-filled email with that same report, with the score and status already in the subject line.
• Run again clears the dashboard and re-runs from scratch (asking for camera and mic again).

A View report toggle shows the exact text the two buttons use, so you can read it before sending. The report includes your browser's user agent and the page origin, but never any audio, video, files, or credentials.

Framing it for a specific call (?mode)

The same six checks can be framed for a specific kind of call with an optional ?mode= parameter, which only reswaps the intro line and the "you're ready" headline:

An unknown or absent mode falls back to the generic wording. The parameter is read-only, length-capped, and never leaves the browser.

White-label for IT teams

Two optional URL parameters let an IT team hand staff a branded, pre-addressed version of the check - no build step, just a link:

• ?org=<name> adds a banner naming the organization and stamps that name onto the report. The banner reads "Meeting readiness for <org>".
• ?support=<email> points "Send to your IT" at that address, so the pre-filled email is already addressed to your help desk. When a support address is set, the banner also shows it, so staff see exactly where the report goes.

Combine them - and the mode - in one link. For example:

https://desktest.net/meeting-check/?mode=agent&org=Acme%20Support&[email protected]

opens the readiness check framed for a work-from-home shift, branded for Acme Support, with "Send to your IT" pre-addressed to the help desk. The organization name is length-capped and only ever displayed; the parameters are read from the URL and never leave the browser except in the email the user chooses to send.

Related tools

Meeting Readiness is a fast summary of several tools that each go much deeper. Open the one a tile points you to:

• Camera Quality Check - delivered frame rate, exposure, backlight, and sharpness in detail.
• Device Selection Check - devices by name, in-use probing, and mic headroom.
• Microphone Test - a fuller look at your microphone signal.
• Speaker Test - per-channel output and device routing.
• Echo and Latency Test - the full echo and round-trip latency measurement.
• Network Test - reachability, DNS, WebSocket, latency, and jitter in detail.
• Call Readiness Test - the broader camera-plus-mic-plus-network call check.

See also About DeskTest.net and the DeskTest.net home.