A Spectrum Peak Is an Observation, Not a Hardware Diagnosis

Adapted from KeyboardTester.click's GPU/PSU coil-whine guide. This engineering note examines the interpretation boundary of its browser analyzer rather than claiming a new physical hardware experiment.

Illustrative PC-maintenance photo: Elias Gámez / Pexels.

A browser can produce a precise-looking number without observing the physical fact a reader thinks that number proves. “8 kHz peak” is an observation about a captured signal. “The PSU is faulty” is a claim about an unobserved component.

The gap is not solved by adding decimal places. It is solved by documenting the capture path, the decision rule and a comparison whose outcome can actually answer the question asked.

Start with the capture contract

The KBT analyzer requests microphone capture with echo cancellation, noise suppression and automatic gain control disabled. That is an application request, not proof that every device or driver supplied unprocessed audio. The selected microphone, browser and operating-system pipeline remain part of the experiment.

A useful preflight is to verify the intended input separately. The SoundTesters microphone check exposes input selection, a waveform and relative digital level, then an explicit local sample-and-playback workflow. Use it to establish that the intended capture path works. Its dBFS display is not an acoustic calibration. Finish capture and stop replay before the separate measurement; playback would contaminate the room signal.

Distinguish bin spacing from measurement accuracy

The analyzer uses an FFT size of 32,768. MDN documents fftSize as the sample-window size used for the frequency-domain analysis.

For a 48,000 Hz context, the frequency-bin spacing is:

48,000 / 32,768 = 1.46484375 Hz

This is a grid calculation, not a claim that the microphone measures a real-world tone to that accuracy. The window spans about 0.683 seconds of samples; filtering, leakage, smoothing, the source and the microphone response still affect the spectrum. The context's sample rate is also not a quality score for the physical capture device.

Record the actual sample rate instead of assuming every device runs at 48 kHz.

Read the peak rule, not just the metric label

Source inspection of the current analyzer shows that its search is limited to roughly 1–18 kHz, with the upper limit also constrained by sample rate and available bins. It rejects peaks below -85 dBFS and estimates a local floor from neighboring bins. A candidate needs at least 12 dB of prominence to be reported.

The selected candidate has the greatest prominence under that rule. It is not necessarily the highest-amplitude sound in the entire recording. Nor is 12 dB an industry definition of acceptable coil noise; it is the detector's decision gate.

Consider these explicitly hypothetical readings:

Prominence alone cannot tell those cases apart. A “better” prominence figure may reflect a different background rather than a quieter tone. Log frequency, digital level and prominence together, with the capture conditions.

Check the algorithm with synthetic inputs

The preparation for this adaptation ran deterministic checks against the repository's exported findTone function, using synthetic arrays rather than microphone recordings. The fixtures cover a flat floor, a qualifying narrow peak, a peak below the level gate, a peak below the prominence gate, a changed floor at constant peak level and competing peaks with different amplitude/prominence.

Those tests establish the calculation's behavior on the supplied arrays. They do not reproduce a microphone, identify a GPU/PSU, validate the acoustic threshold or measure a successful repair. Synthetic correctness and physical validity are separate properties.

This separation is useful even without code changes: it makes a bug report about the decision rule different from a support report about an audible computer.

Treat lifecycle as part of the dataset

The implementation stops capture when the tab is hidden and releases the microphone. This is deliberate privacy behavior, but it changes the measurement procedure. Switching to a full-screen workload may stop the analyzer rather than create a useful under-load sample.

Keep the KBT analyzer and workload visible in separate windows, or capture from a second device. Record interruptions. Do not silently compare a valid capture with a stopped or incomplete run.

For an A/B/A comparison, fix the scene, input, microphone position and gain. Record the original setting, change only an FPS limit, then restore the original setting. If the original pattern does not return, keep the outcome inconclusive. Both GPU and PSU respond to load, so an FPS-linked change does not uniquely identify either component.

Report the result at the observation layer

A defensible result might say: “Under this repeatable scene and capture setup, a narrow peak changed when the frame-rate cap changed, and the initial pattern returned on restoration.” It should not say: “The browser proved the PSU is defective.”

External listening or capture can suggest the next check, while source identity, calibrated sound pressure and component health remain outside the browser's observation boundary. This is a limitation to expose in the product and the report, not a footnote to bury below a confident diagnosis.

Source guide and its practical comparison protocol.

Disclosure: KeyboardTester.click and SoundTesters are owned by the same publisher. This adaptation was prepared with AI assistance and reviewed for accuracy. It reports a troubleshooting method, not a new physical GPU/PSU experiment or a verified repair result.