r/speechtech

I’ve been working on Murmur, a local text-to-speech app for Apple Silicon Macs.

The new feature I’m building is called Projects / Story Studio, and it solves a problem I kept running into:

TTS tools are fine for one-off clips, but messy for actual audio projects.

If you’re making a podcast segment, audiobook chapter, course lesson, ad, or game dialogue, you usually need multiple speakers, multiple takes, pauses, reactions, music, edits, exports, and a way to come back to the project later.

So I built a project-based workflow:

Write a script → assign voices → generate dialogue → edit clips on a timeline → add music/SFX → export final audio.

It supports things like:

• multiple scripts inside one project
• Host / Guest / Narrator / Character speakers
• inline tags like [pause], [laugh], [chuckle]
• per-block regeneration
• timeline editing with waveforms
• media lane for music and SFX
• ripple editing and gap tools
• WAV/M4A export
• transcript and stem export

Everything runs locally on Mac, so long scripts and voice samples do not need to be uploaded to a cloud service.

I’m still polishing the workflow and would love feedback from Mac users, especially people who make podcasts, audiobooks, courses, YouTube narration, or game dialogue.

Most voice input on Android - SpeechRecognizer.createSpeechRecognizer(context) calls — gets routed to Google's network-backed recognizer. I wanted that path to run locally, so I wrote one.

The service hooks the framework's SpeechRecognizer API. Once it's set as the default, any app calling createSpeechRecognizer(context) (no ComponentName) ends up in our pipeline and gets back transcription that never left the device. Pipeline is Silero VAD + Parakeet TDT v3 (114 languages, ~890 MB INT8) on ONNX Runtime with NNAPI.

Honest caveat: Gboard, Samsung Keyboard, and Google Assistant ship their own recognizers and skip the system default. So the default-IME voice button on most phones won't go through this. What does: accessibility tools, custom dictation UIs, and anything calling the framework API directly.

Models download on first use (~1.2 GB) via a foreground WorkManager job so it survives backgrounding. After that, fully offline.

Setup + demo APK: github.com/soniqo/speech-android

audio.soniqo:speech:0.0.9 on Maven Central

Library:

Happy to answer questions about the binder lifecycle, the foreground worker setup, or why SpeechRecognizer is such a tarpit of edge cases.

I put together a dataset-backed benchmark for local voice cloning models:


- OmniVoice int8
- Chatterbox Multilingual fp16
- VoxCPM2 bf16
- Fish Audio S2 Pro fp16


It uses Google FLEURS test clips as references, then reports speaker similarity, WER/CER, generated audio length, and RTF. I also included the reference audio and generated clips for every row, so the table is not just numbers.


Post:
https://www.soniqo.audio/blog/voice-cloning-benchmarks


The result that surprised me most: OmniVoice was the best all-around row set in this run, but the language-by-language behavior is more interesting than the aggregate. VoxCPM2 was strong on Arabic speaker match; Fish Audio had strong German/Arabic similarity but slower RTF; Chatterbox looked good on Arabic/Spanish but I am not benchmarking Chinese until the Swift tokenizer path is ready.


I maintain the Soniqo speech stack, so this is self-promo, but the benchmark is meant to be useful/reproducible rather than a launch post.


Speech Studio is the open-source desktop app built on the same stack:


https://www.soniqo.audio/speech-studio
https://github.com/soniqo/speech-studio


What model/language should I add next?

I've been working on a zero-shot voice cloning TTS system and wanted to share it here in case it's useful to anyone working on similar problems.

What it is

VoxFlash-TTS is a flow-matching based voice cloning model that operates in a heavily compressed latent space — 9 Hz, instead of the much higher frame rates most diffusion/flow TTS systems use. The idea was to see how far latent compression could go before quality breaks down, since lower frame rates mean fewer steps and faster inference for a given NFE budget.

Some of the design choices:

• Phoneme encoder: ConvNeXtV2-based, rather than a standard Conformer/Transformer stack.
• Generative backbone: flow matching with an Euler solver, NFE=16 by default.
• Speaker conditioning: ConvNeXtV2 speaker encoder with attentive statistical pooling, fed into AdaLN.
• Cross-lingual zero-shot cloning: Chinese and English, including code-switching.
• Inference: exported to ONNX, packaged for Docker deployment, no Python training stack required at inference time.

Why 9 Hz

Most latent TTS systems run their diffusion/flow process at much higher temporal resolution. Compressing the latent sequence rate this aggressively is mainly a bet on inference cost — fewer latent frames per second of audio means a much smaller sequence for the flow matching model to denoise, which matters a lot if you care about real-time or low-resource deployment rather than just sample quality in isolation. It's a tradeoff, and I'd be curious to hear from others who've pushed compression in either direction.

Links

• GitHub: https://github.com/VoxFlash/VoxFlashTTS
• Hugging Face: https://huggingface.co/VoxFlashTTS/VoxFlashTTS
• Demo: https://voxflash.github.io

Happy to answer questions about the architecture, the flow matching formulation, or the ONNX export pipeline — these were the trickiest parts to get right, especially the velocity target derivation and keeping VAE latent normalization consistent between training and inference.

Hi everyone,

I just released Qwen3-TTS-Triton v0.3.0.

When I first started this project, my focus was mostly on single-clip latency. In v0.1.0, I fused several hot paths with Triton — RMSNorm, SwiGLU, RoPE, etc. — and combined that with CUDA Graph. That got single-clip Qwen3-TTS inference to roughly ~5× faster than vanilla PyTorch eager on my setup.

For v0.3.0, I shifted the focus a bit.

I tried PyTorch’s new Helion DSL as well, but for this specific workload it only gave me about 1.03× over the existing Triton version. That pushed me toward a different question: instead of only optimizing one sample at a time, what happens if we optimize batched serving throughput for autoregressive TTS?

The result:

Triton kernels + CUDA Graph + batched serving reached ~14× per-sample throughput vs vanilla PyTorch eager batch=1.

Test setup:

• GPU: RTX 5090
• Mode: hybrid
• Batch size: 16
• Model: Qwen3-TTS
• Project: https://github.com/newgrit1004/qwen3-tts-triton

The part I found most interesting is memory efficiency. In the recommended hybrid mode, per-sample VRAM usage drops a lot compared to running each request independently:

• Hybrid batched serving: around 0.49 GB per sample
• Previous single-request style: around ~4.4 GB per sample
• Roughly 6–10× lower per-sample VRAM, depending on the comparison point

I also tried to make sure this was not just a “faster but different output” situation. Batched generation was tested against single-clip generation using my Tier 3 evaluation setup:

• CER distribution
• UTMOS distribution
• Speaker similarity distribution
• Mann-Whitney statistical comparison

The recommended mode right now is hybrid, since it gives the best balance between throughput, memory, and quality-equivalence.

One thing I’ve been thinking about while working on this: Qwen3-TTS is autoregressive, while OmniVoice is non-autoregressive. I also maintain a Triton version for OmniVoice, and working on both has made the AR vs NAR serving tradeoff much more concrete for me. AR TTS feels much closer to LLM serving than I expected, especially once batching, graph capture, and memory efficiency become the bottlenecks.

Links:

• Qwen3-TTS-Triton: https://github.com/newgrit1004/qwen3-tts-triton
• ComfyUI-Qwen3-TTS-Triton: https://github.com/newgrit1004/ComfyUI-Qwen3-TTS-Triton
• OmniVoice-Triton: https://github.com/newgrit1004/omnivoice-triton

I’d be curious to hear how other people here think about AR TTS serving. In particular, whether you think future local TTS systems should optimize more for lowest single-request latency, or for batched throughput / multi-user serving efficiency.

I’ve released Orbination Whisper AI, an experiment in compressing Whisper large-v3-turbo into a compact multilingual speech-to-text engine.

The default model is 368 MB using Q3_K quantization and runs through a Go runtime built on whisper.cpp, with no Python required at runtime. It supports CPU/GPU backends and includes CLI + HTTP server modes.

I focused on reducing the train/inference mismatch by training with the actual ggml Q3_K quantize/dequantize path in the forward pass, using a straight-through estimator and teacher distillation. The goal was to make the exported Q3_K checkpoint behave like the model seen during training, rather than fine-tuning first and losing accuracy after quantization.

WER on held-out FLEURS, using beam search in the deployed Go runtime:

- Q3_K, 368 MB: EN 0.065, ES 0.050, FR 0.065, EL 0.148
- Q4_K, 474 MB: EN 0.062, ES 0.048, FR 0.063, EL 0.124
- Q5_K, 574 MB: EN 0.061, ES 0.047, FR 0.061, EL 0.110
- FP16 upper bound, 1.6 GB: EN 0.061, ES 0.046, FR 0.060, EL 0.108

The interesting part for me is that the high-resource languages stay close across precisions, while Greek shows the biggest sensitivity to quantization.

Repo:
https://github.com/amichail-1/Orbination-Whisper-AI

I’d be interested in feedback from people working with Whisper, whisper.cpp, QAT, or multilingual ASR deployment.

https://arxiv.org/abs/2605.28139

ARK-ASR-3B is a multilingual automatic speech recognition model. It achieves current state-of-the-art results on the Hugging Face Open ASR Leaderboard English short-form benchmark, with an average WER of 5.04%

https://huggingface.co/AutoArk-AI/ARK-ASR-3B

Years of long days at the keyboard caught up with my hands. I got tired of two options: push through the ache, or pay for one of the dictation apps I'd tried (Wispr Flow is $144/yr). So I built my own. It's called Pipevoice. It's free, no account, and the code is on GitHub. I made it, so to be clear, I'm showing it and asking for feedback, not selling anything.

​

How it works: hold a key, talk, let go, and the text drops into whatever app you already had focused. Browser, a text box, your editor, a terminal, doesn't matter. It isn't a separate window you copy out of, so you never have to remember what you said and paste it somewhere. There's a second hotkey that puts the text on your clipboard instead, which I reach for when I'm filling out forms.

​

Two settings I think this sub will care about. One is an accent picker (UK/US/AU/Indian/NZ). The other is a plain notes field where you describe how you actually talk. Mine says "I stutter and use a lot of fillers," and the optional AI cleanup pass uses that instead of typing out every "um." Don't want any of that? Turn cleanup off and it keeps your words exactly as spoken.

​

Cost and privacy both come up a lot, so: free, no subscription, no sign-up. You can run it fully offline with local transcription, in which case your voice never leaves your PC. Or plug in your own API key for a cloud engine if you want it faster. Nothing goes through me either way.

​

A 3-minute demo video is in the post if you want to watch it work first.

​

What I actually want from you all: where does it fall short? If you rely on voice input every day, what breaks in the tools you've used? The accent and speech-pattern side is the part I'm least sure I've gotten right, and I'd rather hear that from people it affects than keep guessing.