I launched a sound test that refuses to pretend the browser can hear your speakers
Most online sound-test websites stop at a play button.
You click it, hear a tone — or don’t — and then you’re left to figure out what the result means.
I launched Online Sound Test on August 3:
The key constraint is simple: a browser can generate a precise digital signal, but it cannot know what actually came out of your physical speakers or headphones.
It can control the frequency, waveform, channel, and level of a test signal. It cannot verify that the left speaker really played, that Bluetooth routed the sound to the expected device, or that the output was clear and balanced.
That limitation shaped the whole product.
Instead of pretending to detect hardware problems automatically, the site:
- Plays a controlled signal locally in the browser
- Asks the user what they actually heard
- Turns those observations into ranked, explainable likely causes
- Provides system-specific repair steps
- Encourages the user to retest after making one change
Output tests do not require microphone permission. Microphone tools ask first and process the signal locally. There are no accounts, and recent test results stay in the browser.
The site currently includes left, stereo, and right channel checks, along with dedicated tools for speakers, headphones, microphones, tones, bass, phase, surround sound, and spectrum analysis.
I have also added guided troubleshooting for problems such as no sound, one silent channel, unbalanced audio, distortion, low volume, and Bluetooth delay.
A Chrome extension is now available too:
https://chromewebstore.google.com/detail/immomndbhlkdffpnindappjfgcfhnmkp?utm_source=item-share-cb
It runs a quick left, stereo, or right channel check directly from the Chrome toolbar. The extension requests no Chrome permissions, does not access browsing history or page content, and opens the website only after an explicit click.
WHERE IT IS NOW
The honest number is that there is effectively no traffic yet.
There is no growth chart, launch spike, or conversion story to share. The product is live and usable, but distribution is still the unanswered part.
My main acquisition bet is SEO.
Audio problems tend to have specific search intent:
- Why is there no sound?
- Why is only one headphone working?
- How do I test my microphone before a meeting?
- Why do my Bluetooth headphones sound bad when the microphone is active?
I have published 12 practical guides so far. Each one starts with a controlled browser test, walks through a specific problem, and leads back to a relevant retest.
The tension is that I do not want to turn the site into hundreds of thin pages written only to target keywords.
I would rather publish fewer pages that genuinely help someone isolate a problem. At the same time, the project needs enough useful surface area for search engines to discover it.
So this is the experiment I’m starting from zero:
- Build useful tools around clear audio problems.
- Publish focused troubleshooting content around real search intent.
- Measure which pages lead people to start and complete a test.
- Improve the paths that produce useful behavior instead of chasing pageviews alone.
For anyone who has grown a free utility site through SEO:
What was the earliest signal that told you your content strategy was working, before you had enough traffic to trust the headline numbers?
The interesting part is that you’ve already defined the acquisition bet pretty clearly: specific troubleshooting intent → useful content → completed tests.
Before traffic becomes large enough to make the numbers obvious, what decision are you hoping the early evidence will let you make — whether SEO itself deserves more investment, or which parts of the current approach deserve it?
Mostly the second one: which parts of the current approach deserve more investment.
I expect SEO itself to take longer to judge. The early evidence I’m looking for is whether specific troubleshooting queries lead to the behavior the page was designed for — starting the relevant test, completing it, and returning to retest after trying a fix.
That should help me decide whether to publish more problem-specific guides, improve the core tools, or strengthen the path between a guide and its relevant test. Even with very little traffic, a few well-matched visits that complete the intended flow would be more useful to me than a larger number of pageviews with no action.
That’s helpful context. The distinction between measuring traffic and measuring whether users complete the intended behavior is an important one.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
The earliest reliable signal isn't traffic, it's rank velocity on your pages. Before volume shows up, watch whether a page climbs 40 → 20 → 12 for its target query in Search Console. Movement toward page one means Google's rewarding it, that's the leading indicator; traffic lags weeks behind.
The second signal fits your product exactly: completion rate on the trickle you already get. No volume needed. If 10 people land on the "one headphone not working" guide and 7 start and finish a test, your content-to-tool path works and you scale it. If they bounce, more traffic won't save it. Behavior on 10 visitors beats pageviews on 1,000.
Which of your 12 guides has the best start-a-test rate so far?
Too early to answer that honestly.
The site only launched on August 3, and none of the 12 guides has enough qualified visits yet to compare start-a-test rates without inventing a pattern from noise.
But your framework gives me a much clearer way to measure the first stage. I’ll watch two things for each guide:
For now, even a small number of matched search visits completing that path would be a useful directional signal, although I wouldn’t treat 7 out of 10 as a stable conversion rate yet.
Once the pages have enough impressions and visits to compare, I’ll share which guide begins separating from the others. The rank-velocity point is especially useful because it gives me something to watch before traffic arrives.