Input level
The bar should move clearly when you speak at a normal volume and fall back when you stop. A bar that barely moves means the gain is too low; one that sits at the top constantly means it is too high and your voice will clip.
Starting the test asks your browser for camera and microphone permission. The stream is rendered on this page and nowhere else — there is no server in this tool to send it to.
A good proportion of “the call quality is terrible” turns out to be a muted headset, the laptop’s built-in microphone being used instead of the good one, or an output going to a monitor nobody is sitting near. Those take thirty seconds to rule out, and this is the thirty seconds.
The bar should move clearly when you speak at a normal volume and fall back when you stop. A bar that barely moves means the gain is too low; one that sits at the top constantly means it is too high and your voice will clip.
The line that trails the level shows the loudest recent moment. Useful for spotting a microphone that only picks up sudden sounds, which usually means a noise gate is set too aggressively somewhere.
A plain 440 Hz sine wave for about a second and a half. If you hear nothing, the problem is the output device or its volume — not the call software, and not the network.
What the browser actually negotiated, which can be lower than the camera supports if another application has it open or a driver is limiting it.
The browser opens the devices, the page renders what they produce, and that is the whole data path. There is no upload, no recording, and no server in this tool — the site it is served from is a set of static files.
You can verify that rather than take our word for it: load the page, disconnect from the network, and run the test. It works, because none of it ever needed a connection. The microphone is also deliberately not routed to the speakers — that would be a feedback loop rather than a test.
If the hardware checks out and calls are still poor, the problem is upstream of the devices. The network health test measures what actually breaks calls: jitter, loss, and what happens to latency when the connection is busy.
No. The stream is opened by your browser and rendered on this page; there is no server in this tool to send it to, and nothing is stored. You can confirm it yourself: load the page, then disconnect from the network — everything still works, because none of it needed a connection.
Browsers do not let a page see cameras or microphones, or even their names, until permission is granted. That is why the device list is empty beforehand — it is a deliberate protection, not a fault with the page.
Usually the wrong input is selected — check the dropdown if more than one appears. After that, check whether the device is muted in hardware (many headsets have an inline switch) or in the operating system's sound settings. If another application has the microphone open exclusively, this page may get silence rather than an error.
Not from a web page, in most browsers. Output device selection is an operating-system setting, and a page is not allowed to override it. Change the default output and play the tone again.
The figure shown is what the browser negotiated for this session, not the hardware maximum. Another application already using the camera, a privacy or bandwidth setting in the browser, or a driver limitation can all reduce it. Closing other applications that use the camera and retesting is the quickest check.
No, and that is deliberate. This checks that the devices themselves work. If the hardware is fine but calls are still bad, the network is the next place to look — the network health test measures the things that actually break calls.