Audio Frequency Test

Introduction

The DeviceHub Audio Frequency Test plays selectable sine tones across common hearing and speaker ranges so you can probe what your output path actually reproduces in the browser. Retail speaker specs list wide response curves; real desks, damaged tweeters, and Bluetooth compression tell a narrower story. Engineers checking a patch cable, musicians verifying a monitoring path, and curious listeners exploring which tones they still hear clearly use discrete frequency selection rather than a single fixed beep. This is a listening aid, not a medical hearing exam and not a substitute for calibrated measurement microphones. Frequency-selective listening finds problems that broadband music hides inside dense arrangements. DeviceHub’s Audio Frequency Test hands you discrete sine anchors across common ranges so you can hear rattles, dead tweeters, and bass roll-off without installing measurement suites. It remains a consumer listening aid: not a medical exam, not a substitute for calibrated mics and REW, and explicit about those limits. Discrete tones also help support agents who cannot hear the user’s speakers: asking “does 1 kHz play cleanly?” is clearer over chat than “does music sound okay?” Sharing exact hertz values in tickets beats vague adjectives like “tinny,” which mean different things to different listeners and slow down hardware replacement decisions.

What this tool does

Choose frequencies from a practical set (for example low bass through upper treble anchors), play pure sines via OscillatorNode, and adjust volume carefully. Status shows the active frequency in hertz. You can move stepwise to find rattles, drop-outs, or harsh peaks. Stop ends the tone immediately. Pair with Bass Test and Treble Test when you want band-focused presets instead of a general frequency picker. A picker or preset list sets OscillatorNode.frequency while gain stays under your control. Mid anchors establish confidence before extremes. Status shows hertz so notes and tickets share exact values. Stop is always one click away because high tones fatigue quickly. Optional comparison workflow: play the same hertz on two outputs back-to-back and write down which device loses energy first. That relative log is more actionable than a single absolute impression. Listing hertz on screen creates shareable evidence for tickets without uploading audio. Users can type the frequency they last heard clearly.

When to use it

Run this test when a speaker sounds dull or sharp, when comparing headphones after EQ changes, when hunting rattles at specific tones, and when documenting which frequencies disappear on a damaged driver. Prefer Bass or Treble pages for quicker low/high checks; use this page for flexible frequency selection across the band. Use it when a speaker buzzes only on certain notes, when comparing EQ profiles, when documenting which highs vanish after a Bluetooth codec change, and when teaching interns how small laptop drivers behave at 80 Hz versus 1 kHz. Jump to Bass or Treble pages when you want curated band presets instead of free selection. Guitarists checking practice-amp DI boxes and synthesizer players verifying MIDI headphone amps also use mid anchors as “is anything coming out” proofs before complex patches. Instrument builders checking practice amps and synthesizer headphone outs use mid anchors as cable continuity proofs before complex patches obscure the signal path. Help desks supporting “my speaker sounds weird” tickets can ask users to play 440 Hz and 4 kHz specifically, turning vague complaints into reproducible steps.

How it works

Web Audio OscillatorNode instances set frequency values in hertz and connect through a GainNode to the destination. Sine waves minimize harmonic distraction so you hear the fundamental the oscillator requests. Small laptop speakers roll off bass naturally; missing 60 Hz is often physics, not failure. Very high tones may be inaudible to some listeners even when the driver produces them. Autoplay requires clicks. No microphone permission is used. All tones are synthesized locally. Pure sines minimize harmonic confusion so the fundamental you dial is what you primarily hear. Equal-loudness contours mean the same gain can seem louder midband than at extremes, adjust by ear. Sample-rate limits can prevent ultrasonic requests from mattering; DeviceHub stays within practical audible anchors. Autoplay requires gestures per start. Local synthesis avoids CDN tone files that could be blocked. Browser audio pipelines may resample; slight pitch shifts are rare but possible on exotic sample-rate routes. If a tone sounds warbled, check Bluetooth interference and CPU load before blaming the oscillator implementation. Avoid scheduling overlapping oscillators from double-clicks; the UI should replace the previous tone when a new frequency starts. Keep sessions short at the extremes.

Step-by-step instructions

1. Set system and on-page volume low, wear headphones if needed, and open the Audio Frequency Test with your intended output device selected in the OS.
2. Play a midrange reference such as 440 Hz or 1 kHz and confirm a clean tone before exploring extremes that are harder to hear or harder on drivers.
3. Step into lower frequencies and listen for disappearance, port chuffing, or cabinet buzz that suggests mechanical limits rather than a silent browser graph.
4. Step into higher frequencies carefully, avoiding prolonged loud exposure, and note where clarity fades on your particular ears and transducers.
5. Optionally compare the same frequency list on a second device to separate hearing limits from hardware roll-off when documenting results.
6. Click Stop when finished so high-frequency tones do not continue unnoticed in the background of a shared space. Jot the highest and lowest frequencies you heard cleanly on this device as a quick personal baseline for future regressions.

Common problems

Inaudible highs can be hearing, age, or tweeter failure, compare devices before concluding. Distortion means turn down. Bluetooth SBC compression can dull highs versus wired. Mono laptop speakers may struggle at both extremes. People sometimes confuse CSS-muted tabs with frequency-specific failure, verify a mid tone first. Users chase inaudible 18 kHz at unsafe volumes, don’t. Distortion means reduce gain, not increase. Phone earpieces may whistle or harshly clip on highs. Mono accessibility does not remove frequency content but can change spatial impression while listening. If all frequencies fail, verify output device before assuming oscillator bugs. Hearing fatigue after long treble sessions biases judgments, take breaks and never evaluate highs at painful levels. Room modes can boost certain bass notes on speakers; headphones reduce that confusion when isolating device response. Pet-startling ultrasonic experiments are out of scope, stay within listed anchors. Hearing fatigue after many highs biases later judgments downward; rest between comparisons. Very quiet mid tones with loud highs usually mean an EQ smile curve or damaged woofer path, not an oscillator bug. Confirm with Bass Test when lows seem missing after highs sound present.

Privacy explanation

Frequency tones are generated on-device only. DeviceHub does not collect which frequencies you played or require microphone access. Stop ends playback; closing the tab tears down the AudioContext. Which frequencies you audition are not reported to DeviceHub servers. No microphone listens while you play tones. End the session with Stop so high-frequency energy does not continue unnoticed. Frequency choices are not mined for marketing. Playback-only permission surface means you will not be asked for a microphone during this test. Closing the tab is enough to end oscillators; there is no background service worker synthesizing tones after navigation away from this diagnostic. DeviceHub does not retain a playlist of tones you tried; each click exists only for the live AudioContext in your tab.