Design notes: client-side TTS/STT

Working notes from designing Phase 1.1 (browser-native speech vs. WASM).

It's not reliable

both errors (network for STT, synthesis-failed for TTS) point at the same root cause: Chromium's Web Speech API on Linux leans on backends (Google's cloud for STT, a shaky OS-bridge for TTS) that just aren't reliable in this environment.

That's genuinely useful signal, not a failure of the widget — it confirms the instinct from earlier that browser-native Web Speech isn't a solid foundation for this project, and the offline sherpa-onnx-WASM route is worth prioritizing when we pick this back up.

WASM and client-side download

Verified — good news, this is very doable, and there's a nice simplification: piper voices aren't a separate integration from sherpa-onnx, they're bundled into it. 129 piper voices are pre-converted and hosted directly for sherpa-onnx's TTS runtime — so "piper in the browser" and "sherpa-onnx in the browser" are the same thing, not two paths to choose between.

sherpa-onnx-wasm — official, prebuilt, no build step needed: - Real HF Space demos exist for both directions: TTS (huggingface.co/spaces/k2-fsa/web-assembly-tts-sherpa-onnx-en) and ASR/STT (.../web-assembly-asr-sherpa-onnx-en), with the JS glue + .wasm + .data files visible directly in each Space's source — you can lift the bundle as static files, no Emscripten compilation required. - Covers both TTS and STT from one consistent toolchain — matches the voice-tutor use case (needs both) and matches what you already trust/use locally. - Serves as plain