DEV Community: 王冲

Our Analytics Said 49 Visitors. The Truth Was ~10.

王冲 — Sat, 10 Oct 2026 02:05:00 +0000

We launched Elmren Voice — a local-first Mac app that clones a voice from 10 seconds of audio and turns any reading into a read-along player — on Product Hunt this week. Zero audience, no hunter, no mailing list. The dashboard lit up the next day: 49 unique visitors.

I almost screenshotted it. Then I looked closer, and the number fell apart.

The pattern that killed the number

We ship a localized site (11 languages) with ~330 indexed URLs. Filtering the raw event stream in PostHog, one fingerprint showed up everywhere:

Every localized page hit exactly 2 times. Not 1, not 3 — 2. Real visitors don't schedule themselves like that.
All of it marked "Mac OS X", all of it $direct, sessions spread across every language version we ship — including languages that had never sent us a single human.
Datacenter ASNs and obvious bot flags were already excluded. These weren't. Multilingual SEO crawlers walk your sitemap wearing a consumer OS user agent and your analytics believes them.

The dedup check we now run daily (HogQL, adapt to your stack):

SELECT uniqIf(distinct_id, event = '$pageview') AS visitors
FROM events
WHERE timestamp >= yesterday() AND timestamp < today()
  AND properties.$host IN ('elmren.com', 'www.elmren.com')
  AND NOT coalesce(properties.$virt_is_bot, false)
  AND coalesce(properties.$geoip_city_name, '') NOT IN
      ('Ashburn','Council Bluffs','Reston','Boardman','Des Moines','Clifton')  -- datacenter cities

Then one more pass: group pageviews by URL and look for the "every page exactly N times" signature. If your per-language counts are uniform, you're looking at a crawler, not a market.

What was left after filtering

Product Hunt launch day: 6 visitors. Not 600. Six.
Best post-launch day: ~10. That "49" was ~80% crawler.
Some days since: genuinely zero. We verified the pipeline itself wasn't broken by sending test events through the same collector — pipe healthy, humans absent.
Sales: 0. Which, at 2–3 visitors/day, is not a conversion problem. It's arithmetic: even a great 3% visitor→trial→buy funnel needs ~30+ visitors/day to produce a sale a month. Traffic is the bottleneck, and no amount of landing-page polish fixes a denominator.

The number that's actually going up

Google Search Console impressions, week over week: 123 → 177 → 362. One click so far, average position ~14. The first page to rank isn't in English — it's Dutch (tekst voorlezen nederlands, position 8): a long-tail "read text aloud" query where the incumbents are thin and a localized page can actually win.

That's the real shape of a zero-audience launch: social spikes evaporate (ours never materialized), but indexed, localized, genuinely-useful pages compound. Our plan now is boring on purpose — keep shipping content pages in languages where the competition is weak, keep the scoreboard honest, and let the denominator grow before we judge the funnel.

Three things we changed because of the filtered number

The scoreboard reads filtered numbers only. A daily notification with "visitors X/100 (bots excluded)". Unfiltered numbers get rounded up by robots and round down your judgment.
We stopped celebrating channel spikes and started auditing them. Any spike gets the URL-uniformity check before it earns an emotion.
Roadmap re-ordered around the denominator. Localization depth and long-tail content beat another coat of paint on the homepage.

If you're pre-audience right now: filter your traffic before you interpret it. The gap between 49 and 10 is the gap between "growth is happening" and "growth hasn't started yet" — and only one of those diagnoses leads to work that matters.

Elmren Voice is $39.99 once, runs entirely on your Mac (no cloud), and the read-along player it exports works in any browser. If you're curious: elmren.com.

One HTML File, Zero Requests: Building a Read-Along Player With Word-Level Highlighting

王冲 — Sun, 04 Oct 2026 16:01:50 +0000

My favorite artifact from the app I'm building isn't in the app. It's the file the app exports: a single HTML page that plays a chapter of audio while every spoken word lights up in sync — karaoke-style — with zero network requests, zero dependencies, zero accounts. Open it on a phone from 2015 with airplane mode on; it works. Email it to a grandparent; it works.

This is the heart of Elmren Voice, a local-first text-to-speech app for Mac I've covered here before — how I picked the TTS engine, then how I packaged the Python sidecar. This post is the last leg: how synthesized audio becomes a self-contained read-along player, and the alignment trick that makes the highlighting exact.

Why a file instead of a page on our server

The product's promise is that a child's reading material and a family's voice recordings never leave the machine. A hosted player — even a nice one — would break that promise the moment playback needed a server. A plain file keeps it: generate locally, open anywhere, and the privacy story is structural instead of contractual. It also means the thing you made in 2026 still works in 2036 regardless of anyone's business model, including ours.

The constraint drove the format: one HTML file, audio embedded as a data URI, the word-timestamp table inline, and a few hundred lines of dependency-free vanilla JS for the highlighter.

The pipeline: text → audio → word timestamps

Synthesis runs sentence-by-sentence (that's a cloning-quality requirement, not a design preference). Then the generated audio goes through whisper.cpp for alignment — not transcription quality, alignment. The numbers from my reference machine: 58.8 seconds of audio → complete word-level timestamps in 2.87 seconds.

Then the part nobody warns you about.

Whisper mishears words. The highlighter must not care.

The timestamp says when a word was spoken, but the transcript whisper produces says what it heard. Feed the transcript's words straight into the UI and you get the classic failure mode of naive karaoke: the highlight drifts to what was heard while the page shows what was written, the kid's eyes track the wrong word, and the whole point of read-along — eyes locked on the correct print — collapses.

The fix: the highlighter renders the source text, never the transcript. The source is ground truth (it's literally what we sent to the TTS engine); the transcript is only a carrier of timing. A SequenceMatcher pass maps each transcribed word to its counterpart in the source — on my 166-word reference passage it covers 166/166 words — and any word whisper dropped or mangled simply inherits timing from its neighbors. Mishearings degrade to slightly looser sync, never to highlighting the wrong word.

If you build anything with forced alignment, this inversion — source text for rendering, transcript for timing only — is the whole ballgame.

The runtime: boring on purpose

The player itself is deliberately uninteresting technology, which is the compliment: an <audio> element, a word table, and a timeupdate-driven binary search for the current word. A <span> per word gets a class toggle. Pages chunk by paragraph so a long chapter never renders a wall of ten thousand spans at once. There's a progress memory in localStorage, a dark mode that respects prefers-color-scheme, and — because some kids share devices with siblings — everything also works with the keyboard alone.

No framework. The file has to outlive every framework.

The same timestamps, two more products

Once word timing exists, it composes:

M4B audiobook export — chapters and bookmarks straight from the sentence boundaries the pipeline already knows.
Karaoke MP4 — the word-highlight render as video. The shipped ffmpeg build carries no subtitle filters, so it's rendered per-word as PNG frames and concatenated — a constraint I've written about before, and frame-exact highlighting came out of it.

One alignment pass, three deliverables.

What it looks like

There's a live demo player up — it's a real export from the product (a chapter of The Secret Garden), not a mockup: play it and watch the words light up. The app itself is $39.99 once for macOS, with a free trial (120 synthesis minutes in your first week), and voices are either one of the 64 built-in or a clone of your own — learned and spoken entirely on your Mac.

One more thing: Elmren Voice launches on Product Hunt tomorrow, Tuesday Oct 6. If read-along tooling for kids who struggle with reading is your corner of the world, I'd genuinely value a look — and criticism; the comment threads are where the good corrections come from.

As before, thanks to the stack that makes a one-person product possible: whisper.cpp, Kokoro, Qwen3-TTS and mlx-audio.

Packaging a Python ML Sidecar Inside a Signed Mac App: 9 Traps from Production

王冲 — Sun, 04 Oct 2026 14:37:29 +0000

In my last post I covered how I picked the TTS engines for Elmren Voice — a Mac app that clones your own voice locally and turns any text into a read-along player with word-by-word highlighting. Everything runs on-device: no cloud, no API keys, no account.

That post was the fun part. This one is the part nobody warns you about: getting a Python ML stack to live inside a signed, notarized, sandbox-friendly Mac app — and keeping the download at ~122MB while the models themselves weigh gigabytes.

The stack: Tauri 2 shell (Rust + React/TypeScript), Python sidecar for the engine (mlx-audio, Kokoro, whisper.cpp, ffmpeg). Nine traps, all paid for in real debugging hours.

1. Your sidecar "launcher" silently swallows arguments

The packaged launcher must start with no arguments. My first build passed rw-engine --serve style args through a wrapper that resolved to python --serve — Python happily starts an interactive session and your bridge never handshakes. Symptom: app launches, engine "runs", zero responses. The fix is boring: the launcher takes nothing; the serve mode is the default; mode switches ride the JSONL protocol, not argv.

2. Version your wire protocol… as strings

Our bridge is newline-delimited JSON over stdin/stdout. Every message is enveloped, and the envelope is {"v":"1"} — v is a string. I shipped one call site with a numeric 1 once. Strict parsers see two different protocols. Pick string versions on day one; JSON numbers will bite you across languages (Rust serde and Python json disagree on int-vs-float edge cases).

3. Control commands must never queue behind data commands

The nastiest bug I shipped: user clicks Cancel on a synthesis job — nothing happens. Why? One mutex guarded the whole stdio bridge, and a 10-minute chapter synthesis held it on every roundtrip. The cancel command was delivered, then sat in the write queue behind the job it was supposed to kill.

The fix, shipped in v1.9.1: split the hub into a data plane (long roundtrips) and a control plane (short commands: cancel, pause, settings) with an independent write-side lock, and make control messages fire-and-forget. Cancels now land even mid-roundtrip. If your GUI freezes "sometimes" during long native calls, audit your lock topology before anything else.

4. PEP 668 means zero runtime pip. Ever.

Modern macOS Pythons are externally managed; runtime pip install was never going to survive anyway (no compiler, no network assumptions, Gatekeeper). The rule that falls out: the entire Python environment ships inside the app as a vendored sidecar-site — including things you'd normally pip install at build time, like en_core_web_sm for spaCy. If a wheel can't be vendored, that dependency doesn't exist.

5. brew's whisper-cli dies on every machine but yours

whisper.cpp does our word-level alignment. The Homebrew build hardcodes its ggml backend search path to the Cellar absolute path — on my dev Mac, perfect; on a clean Mac, Abort trap 6. The only reliable answer is building from source statically: v1.9.2, BUILD_SHARED_LIBS=OFF, Metal embedded. One self-contained binary, seeded on first launch.

6. Hardened runtime rejects your relocated dylibs

Relocating Python extension modules and native tools means library paths that no longer match their signatures. Under Hardened Runtime (required for notarized distribution) that's a hard kill at load. You need disable-library-validation in the signing entitlements for those binaries — plus re-signing them after every copy/move. Also: keep native binaries in their own native-tools/ tree, or your Rust build will try to scan Mach-O files sitting inside the Python site-packages and waste minutes per build.

7. The bundled ffmpeg has no subtitle filters. Karaoke videos anyway.

The redistributable ffmpeg build carries no ass/drawtext filters, which kills the obvious "render word-highlighting onto video" path. The workaround that shipped: render each word as a PNG, concat them per-frame, and pad the video to audio length. Less elegant, zero extra dependencies, and frame-exact highlighting came out of it. Constraint beat cleverness.

8. A symlink in your data root is a jailbreak

Users will symlink ~/Application Support/.../models to an external drive. Tempting to allow — until path resolution follows the link out of the sandbox root and your escape checks pass things they shouldn't. Our PathService.resolve follows links and rejects any path that escapes the data root; the supported path for moving data is cp -cR (clonefile, near-free on APFS). Related: Hugging Face downloads behind some proxies hang forever on the new Xet channel — HF_HUB_DISABLE_XET=1 forces the classic HTTP path.

9. Ship thin, hydrate on first launch

The final architecture: the DMG is ~122MB — app shell, UI, a sample book, and no models. On first run the app downloads engine packs on demand: ~700MB for the base stack (54 Kokoro preset voices + alignment + media), ~1.7GB adds the multilingual set, ~2.3GB all-in with the Qwen3-TTS cloning engine (64 voices total). Downloads are cancelable, disk space is pre-checked, and a background reconciliation loop repairs interrupted packs. First launch went from "download 2.3GB before you see anything" to "usable in a minute, clone-ready when you are."

The takeaway

A local-first AI product is two products: the ML pipeline, and the distribution engineering around it. The second one has no benchmark blogs. If you're heading down this road: vendor everything, sign everything, keep your control plane off your data plane's locks, and treat every binary that worked on your machine as untested.

I'm building Elmren Voice ($39.99 one-time, macOS 13+) — there's a live demo player exported from the real product if you want to hear the word-highlighting in action. Engine selection backstory in part 1.

Update (Oct 5): Elmren Voice launches on Product Hunt this Tuesday, Oct 6. Part 3 of this series — how the read-along player with word-level highlighting works — is up.

Three Bake-offs to Find a Voice Cloning Engine That Runs Entirely on a MacBook

王冲 — Fri, 02 Oct 2026 09:15:18 +0000

I'm building a Mac app where a parent clones their own voice on their own machine, and the app turns reading homework into audio with word-by-word highlighting — aimed at kids with dyslexia who can follow along while listening. The hard requirement came from the use case: a child's voice samples and reading materials never leave the laptop. No cloud calls, no subscription, no telemetry. Everything runs locally on Apple Silicon.

That meant finding a TTS engine that can (a) clone a voice from ~6 seconds of reference audio, (b) run at or near real time on a base M1 Pro, (c) be commercially usable, and (d) be small enough to ship inside a desktop app.

It took three bake-offs, five engines, and a pile of traps. Here's what I learned — including one lesson that flipped the whole result.

First, the license minefield

Before any benchmark: most of the famous zero-shot voice cloning models are legally unusable for a commercial product.

F5-TTS — CC-BY-NC. Non-commercial. Out.
XTTS-v2 (Coqui) — CPML. Out.
self-hosted fish-speech — research license. Out.

That leaves the Apache/MIT family: Kokoro-82M, ZipVoice, Chatterbox (MIT), and Qwen3-TTS. All benchmarks below ran on a MacBook Pro M1 Pro / 32GB, cloning the same reference voice (a LibriVox narrator, 60s of dense speech) reading ~40 seconds of Peter Rabbit.

Round 1: The obvious candidates

Chatterbox: one-shot generation of the full 40s passage. The output sounded fine. The problem was speed: 808 seconds of compute for 40 seconds of audio (RTF 20). On MPS it's an order of magnitude too slow for a consumer app. Out.

ZipVoice (123M, from the k2-fsa folks): genuinely fast — per-sentence wall clock of 10–16s including ~7s of model loading per call, which works out to roughly RTF 0.6–1.5 once you keep the model resident. But it had sharp edges:

The prompt text must exactly match the prompt audio. A 28s reference clip paired with only the first sentence's transcript produced 44 seconds of that one sentence repeated forever. A 6s clip paired with a 28s full transcript produced 0.4–2s fragments. Exact 6s/6s — perfect.
Batch mode on MPS misbehaves: the same inputs that work per-sentence went into repetition loops in batch mode. Suspected padding bug. Production pipeline calls it one sentence at a time.
The zipvoice package on PyPI is an empty shell — the real code is pip install git+https://github.com/k2-fsa/ZipVoice, plus a handful of dependencies that aren't declared.

At this point ZipVoice was the front-runner: near-real-time, Apache-2.0, 468MB.

Round 2: Qwen3-TTS-0.6B on PyTorch — "local is impossible"

Qwen3-TTS-0.6B-Base is Apache-2.0 and the community reported RTF 0.86 for cloning. But every one of those numbers came from CUDA. On the M1 Pro, with the official qwen-tts package:

MPS + bf16: crashes in the embedding layer (Placeholder storage has not been allocated), on both torch 2.9 and 2.13.
CPU, fp32: seven minutes, zero output.
MPS + fp32 with device_map: runs — at RTF ≈ 9. A ten-word sentence took ~6 minutes. Fifteen times slower than ZipVoice.

There's a second trap with Qwen's in-context-learning (ICL) cloning: it's extremely sensitive to reference audio quality. A trimmed reference clip fed with the full-length transcript generated garbage that ran to the token limit — mostly silence and noise.

I wrote it off: local Qwen3-TTS on M-series is unusable today. I planned to fall back to a cloud API for the premium tier and keep watching for MPS support upstream.

Round 3: Same weights, different runtime

The round-2 verdict was only true for PyTorch. The community had already ported the weights to MLX: mlx-community/Qwen3-TTS-12Hz-0.6B-Base-bf16 (2.4GB), running through mlx-audio.

Same model, same machine:

Metric	PyTorch (MPS)	MLX
Average RTF	~9	0.88
Model load	minutes / crashes	1–2 seconds
Content correctness	—	7/7 sentences correct on whisper round-trip

Faster than real time. Suddenly the "unusable" model was the fastest cloning engine of everything I'd tested, with the best quality-to-size ratio.

The biggest lesson of the whole project: the model card is not the performance story — the framework port is. If a model looks too slow on your platform, check whether someone has re-implemented it for your runtime before you write it off.

The gotcha that cost the most time

Qwen's ICL cloning demands that the reference audio be sentence-aligned at the start, with a verbatim transcript. Feed it a sloppy reference and it doesn't degrade gracefully — it fills the output to the token ceiling with noise. Interesting contrast: ZipVoice eats dirty references without blinking; Qwen does not.

So the product pipeline is now mandatory for any engine:

record → whisper transcript → trim at sentence boundaries → feed engine

A few more hard-won environment notes, in case you're walking the same road:

Hugging Face downloads through a proxy can hang forever on the new Xet channel — zero bytes, zero errors. export HF_HUB_DISABLE_XET=1 forces the classic HTTP path and fixes it.
Reference length is your biggest speed lever. A 28s reference re-encodes per sentence (RTF 7–94 in the worst case); 6s drops it to 1–5. Guide users to record 6–10 clean seconds.
In mlx_audio.generate_audio, output_path is a directory and file_prefix is the filename.

4-bit quantization won on every axis

Before shipping, I compared the 4-bit quantized weights against bf16, expecting a quality cliff:

Speaker similarity (resemblyzer): 0.928 (4-bit) vs 0.923 (bf16)
Content fidelity (whisper round-trip): 0.992 vs 0.992 — parity
Speed: RTF 0.63 vs 1.11 — 4-bit is nearly 2× faster
Size: 1.71GB vs 2.4GB

Cross-similarity between the two arms was 0.937 — effectively the same voice. An F0 analysis confirmed quantization didn't flatten prosody. The download pack ships 4-bit.

The supporting cast

Kokoro-82M (Apache-2.0, 0.39GB as MLX bf16) for the 54 preset voices — story-time character voices, script mode, etc. English is its A-tier language; we only use it as a complement.
whisper.cpp (MIT, static build) for word-level alignment — the thing that makes karaoke-style highlighting possible. 58.8s of audio → complete word timestamps in 2.87s. One subtlety: the timeline comes from whisper, but the word shapes come from the source text; a SequenceMatcher maps one to the other (166/166 words covered on the reference passage), so whisper mishearings don't corrupt the highlighting.
Shell: Tauri 2 + React/TypeScript + Python sidecar, with the engine abstracted behind a provider interface — because MLX is Apple-only, and the Windows path (ZipVoice on CPU, or a cloud fallback) is phase two.

Real-world throughput on the M1 Pro: ~1–2.5 minutes per 1,000 characters (idle to loaded), a full ~10-minute chapter processes in the background in 10–25 minutes, and power draw is a rounding error (~0.2Wh per chapter by estimate — the battery doesn't notice).

What this adds up to

A parent records 6 seconds of reading, and a few minutes later a self-contained HTML player exists with their voice reading the chapter, words highlighting as they're spoken. No cloud, no API keys, no monthly fee — which is only possible because of how good the Apache/MIT TTS ecosystem has gotten, and because of the MLX port of Qwen3-TTS.

If you're evaluating local TTS on Apple Silicon, the short version: Kokoro for preset voices, Qwen3-TTS-0.6B (4-bit, via mlx-audio) for cloning, whisper.cpp for alignment — and budget a day for the reference-audio pipeline, because that's where the quality actually lives.

I'm building this as Elmren Voice ($39.99 one-time, macOS 13+). There's a live demo player exported from the real product if you want to hear the word-highlighting in action.

Thanks to the maintainers of mlx-audio, Qwen3-TTS, Kokoro, ZipVoice, and whisper.cpp — this product only exists because your licenses and ports do.

Update (Oct 5): Elmren Voice launches on Product Hunt this Tuesday, Oct 6. Part 3 of this series — how the read-along player with word-level highlighting works — is up.

I built a body-doubling focus app: no camera, no booking, no signup to look around

王冲 — Sat, 01 Aug 2026 11:18:06 +0000

I kept noticing that the thing stopping me wasn't what to do — I knew that. It was the act of starting. So I built Dopastep, and the whole design is about removing reasons not to start.

(Disclosure up front: this is my own project. Feedback, including the harsh kind, is why I'm posting.)

The two things it does

Breaks the task down. You name the thing you've been circling for three days, and it gets split into steps small enough that the first one isn't a decision.

Puts other people in the room. You drop into a live focus room and work in synced focus/break cycles alongside whoever is there. That's body doubling — the effect where someone else working nearby makes it easier to begin.

What I deliberately left out

I used Focusmate for a while and it genuinely helped, but two things eventually killed it for me: the camera, and the booking. By the time a session was scheduled, the window where I could actually have started had closed.

So Dopastep has no camera, no chat, no booking and no partner matching. You open a room, see how many people are in it and which phase the shared timer is in, and start. No account needed to look around.

Two implementation notes

The timer is derived, not synced. Everyone in a room has to agree on which phase they're in, including people who joined late or just refreshed. Rather than broadcasting ticks, the phase is computed from a single server-held start time. Late joiners and refreshes land in the right phase for free, and a whole category of "my timer says 3 minutes, yours says 5" bugs never exists.

Occupancy has to be honest, including when it's zero. The entire value proposition is "someone else is actually here", so an inflated number would poison the one thing the product is for. Presence runs over Supabase Realtime, and an empty room says it's empty. This is commercially the wrong choice and I'm keeping it.

Stack, if useful: Next.js 16, React 19, Supabase, Tailwind v4, deployed on Vercel.

Where it actually is

Launched in July 2026. Outside one scheduled session a day the rooms are usually empty — which, for a product whose point is other people, is the problem rather than a problem. That's the part I'd most like to hear ideas on: how do you bootstrap something that only works when someone else shows up?

https://dopastep.com/

Happy to answer anything about the presence setup or the timer derivation.