FAQ

Symptoms. The FFT discards windows with "Found signal discontinuity - re-synced", the scope's glitch trigger fires, the capture rate drops - and when the measurement runs on a bench it happens with WASAPI, WDM-KS and JavaSound alike, while the analog output, checked with an external oscilloscope, is perfectly continuous. A local Web Audio capture raises the same warnings: the browser's shared audio path can drop samples too, and the warning means the same thing there.

What it is. Genuine sample loss in the OS/USB stack below the application, on the machine the interface is plugged into - the bench when you measure through a server, not the machine showing this page. The capture path cannot create gaps by design - the ring buffer accepts every delivered sample and each consumer keeps its own overrun-protected cursor - and both detectors (the scope's glitch trigger and the FFT's time gate are the same detector class) fire on the signal itself, so what they report is a real splice in the stream. The same loss is known to affect other measurement software on the same machines.

Typical cause. An overloaded or degraded USB host controller: several high-traffic devices sharing one controller, a hub shared with disks or cameras, or controller/driver state that has degraded since boot - a reboot often clears the problem for a while before it returns.

Remedies. On the machine that owns the interface - the bench, or this machine for a local capture - connect the audio interface to a dedicated USB controller: its own PCIe USB card, or at least a port group no other high-traffic device shares. Avoid hubs, especially hubs shared with storage, cameras or network adapters. A reboot resets the controller state and buys clean time; if the problem creeps back, the controller load is the thing to fix.

Why it looks worse at high frequencies. A splice of n lost samples steps the waveform by roughly A · 2πf/f_s · n - proportional to the signal's derivative. The same loss rate that is barely visible on a 2 kHz tone fires the detectors constantly on a 5 kHz tone at the same amplitude. When comparing before/after a hardware change, compare at the same tone frequency.

Symptoms. The device offers a single sample rate - in this application and in every other one - and the rate list cannot be changed from the operating system's sound settings either.

What it is. Some interfaces do not take their clock from the host at all: the rate is selected in the manufacturer's own control utility, and the driver then presents that one rate to the system. Audient-class interfaces work this way. Nothing above the driver can override it - the operating system and every application can only use the rate the utility has selected.

Remedy. Open the manufacturer's control utility, set the rate there, then rescan devices in Preferences so the new rate is picked up.

Symptoms. Starting a capture fails and the device is reported as unavailable or already in use.

What it is. The device is held elsewhere, and there are two cases. On a bench it is an exclusive-mode conflict on the server: its backends take the device exclusively, so exactly one client measures on it at a time - the device list names the client that holds it, and a device shown as locked stays locked until that client releases it. Locally it depends on the backend. Web Audio shares its audio path and claims nothing exclusively, but the device can still be held by another application, or by the system's own sound panel while it shows a level meter for it, and the browser is refused as well. A QA40x reached over WebUSB is the other way round: the analyzer is claimed by one application at a time, so it must not be open in the QuantAsylum software or in another tab, and a claim that fails leaves the analyzer unopened here. Neither this page nor the server holds a line across captures: a device that is not being measured with is released, so an earlier measurement of your own is not what is blocking it.

Remedies. For a bench device, wait for the client the list names, or pick another device. On Web Audio, close the application that holds the device, and the sound panel if it is open on that device's page; for a QA40x, close the QuantAsylum software and any other tab that has claimed the analyzer. On the machine that owns the device, check its exclusive-mode allowances in the system sound settings - a device that forbids exclusive use cannot be measured bit-exactly there. Then retry.

What happens. When a measurement starts on a bench running Linux or macOS, the card's hardware volume controls are set to unity gain on that machine, and they are put back to their previous positions when it ends. The bench does this itself: a browser reaches no mixer at all, so a local Web Audio measurement changes nothing and cannot compensate for a volume that is not at unity.

Why. A measurement states levels in volts and in dBV, which is only meaningful when digital full scale maps to a known analog level. A hardware volume anywhere in the path scales that mapping without appearing in the data, so a figure measured at one slider position would not match the same measurement made at another. Pinning the controls to unity gain removes that unknown, and restoring them afterwards leaves the card as it was found.

The broad case. The controls are matched by port name. On cards whose controls match no port name, every volume control of the card is pinned - and every one of them is restored afterwards.

The device scanner's report. The project ships a standalone diagnostic beside the application: a self-contained jar, one jar for every operating system, attached to each release. It runs on the machine that owns the hardware - the bench when you measure through a server, or a machine running the desktop application - never in the browser.

Run it from a terminal there:

java -jar device-scanner-<version>.jar

What it does. It enumerates every audio backend present on the machine cache-free - it builds fresh device managers, so every figure in the report was probed by that run rather than read from a cache - and writes a human-readable device-scan-<stamp>.txt in the working directory, listing every device with its supported sample rates and bit depths. No stream is opened.

Attach that file. It answers, in one place, which backends the machine has, which devices each of them sees, and what formats those devices really accept. For a problem seen in the browser, name the browser and its version as well, and add what the page printed to the developer console.

No, and that is by design. The server is a bench instrument for a trusted network, which is what the server documentation states as well. It carries no user accounts, no passwords and no tokens.

What that means in practice. Anyone who can reach the server on the network can use the bench: list its devices, drive its generator and take its measurements.

How to run it. Keep it on the trusted segment it was meant for, and do not expose it beyond that - no port forwarding to the internet, and no untrusted network. Where the reach has to be wider, put the access control in front of it, in the network rather than in the instrument.