What's everyone using for Speech to Text?

[peteonrails]

I have been following the interest in #2467 for speech-to-text integration. I like the work goodroot has done on hyprwhspr, but I am not personally a big fan of python implementations for this kind of utility. Having tried a number of other python STT tools, I get caught up in dependency hell pretty quickly.

After not finding exactly what I wanted in the community, I built Voxtype as a Rust and Whisper-based speech-to-text tool. I'm not trying to compete with hyprwhspr, but offering an alternative with some different trade-offs that might appeal to the Omarchy philosophy.

Voxtype is built as a single Rust binary because I prefer compiled tools rather than interpreted ones for stuff like this. I found Python venvs painful to manage, and often ran into dependency conflicts or incompatibility issues.

It's offline-only by design, so you'll have the best experience if you have a decent GPU. GPU support via the Vulkan backend works across GPU vendors. I ran in to some ROCm 7.x compatibility issues when trying out hyprwhspr and other similar python implementations.

I decided that I wanted desktop notifications in addition to a waybar widget to give me visual feedback when recording/transcribing. And also audio cues.

Trade-offs:

• No cloud fallback. I don't plan to add this feature and don't really want it, but I would consider well thought-out pull requests if a lot of people ask for it.
• No Parakeet model support

Happy to prepare a PR if there's interest, or help evaluate both options. The community clearly wants speech-to-text - just offering another option to consider.

https://voxtype.io | https://github.com/peteonrails/voxtype

[lukejmorrison]

I’m currently using hyprwhspr with push-to-talk (SUPER+F2) and a Waybar widget for state/tooltip feedback, plus audio cues. Because I’m on an older GTX 1070 Ti (Pascal), I moved transcription to a local REST backend (Parakeet) to avoid whisper.cpp/CUDA build issues — but that also means my GPU isn’t being used, which is exactly the kind of “same problem” you’re describing. I think?

If Voxtype is the direction, what I’d love is:

A stable Waybar integration contract: a command that prints Waybar JSON (text, class, tooltip) reflecting state (idle/recording/transcribing) + active model/backend/device.
Push-to-talk that plays nicely with Hyprland press/release binds (either voxtype ptt-begin / voxtype ptt-end, or a single long-running voxtype ptt process that can be stopped on key release).
Output options matching my current ergonomics: copy transcript to clipboard and that allows a user to optionally perform a manual paste using SUPER+V if the wrong feild was focused and the transcript wasn't pasted but is still in the clipboard.

Haveing support for legacy GPU backends that works on older NVIDIA via Vulkan (so Pascal actually accelerates locally) + optional notifications/audio cues built-in.

That would let me keep my current UX (SUPER + F2/hotkey + visual Waybar feedback) and make it so I can take full advantage of my older 1070 Ti without Python/venv/CUDA like you say.

[peteonrails]

Thank you for this feedback - I really like a lot of these ideas. Some of them are pretty light lifts, others a little heavier.

The good news is that voxtype provides:

voxtype status --follow --format json
{"text": "🎤", "class": "recording", "tooltip": "Recording..."}
{"text": "⏳", "class": "transcribing", "tooltip": "Transcribing..."}
{"text": "🎙️", "class": "idle", "tooltip": "Voxtype ready - hold hotkey to record"}

And it'd be super easy to show model/backend/device - I'll put that on the backlog and get that started.

We also provide:

  mode = "clipboard"

It works as you've described above. If you enable "paste mode" it will auto-paste. Otherwise it leaves the transcription on the clipboard.

I don't make a prebuilt binary for Vulkan yet, but I have been considering packaging it. But today, you could rebuild the package with cargo build --release --features gpu-vulkan and it would use your GTX 1070 Ti (I used to run the same card!)

The biggest gap I see is the integration with Hyprland's bind keys. To clarify, are you thinking that you want something like this:

  bind = $mod, F2, exec, voxtype ptt-begin
  bindr = $mod, F2, exec, voxtype ptt-end

I have a couple of ideas about how I might support that and still support other compositors and non-Wayland systems. Let me think that through a bit and get back in a few days.

THANK YOU for your input!

[peteonrails]

@lukejmorrison Version 0.4.0 of voxtype supports hyprland and sway compositor keybinding mode for triggering input. If you use this mode, the user no longer needs to be a member of the input group. I'll be packaging a deb, rpm, and AUR release with this new functionality.

I hope you'll give it a try -- if you do I'd be very interested to hear how it performs on the GPU.

[lukejmorrison]

I've been mucking around with your code, comparing it to Hyperwhspr and trying to add a few Waybar/Hyperland features

[peteonrails]

Thanks, I'd love to hear how it goes.

[lukejmorrison]

Here's an idea of what I've been playing with so far:

https://youtu.be/RewdhdLBkqs

Omarchy_251218_voxtype-showcase_v4.md

The Transcribings:

"Oh, there we go. And then it starts transcribing and you see a little bit of dynamic feedback. So you know that you're actually transcribing. Because before I was doing that and it was annoying because I would be talking to myself and then I realized I hit the key and it's not transcribing and it just started. So I lost a whole bunch of stuff that I had said. So I thought, I wonder if we can make this connect in there, which I guess with the flexibility of Arch and Amarchi and all that. It's fairly easy to do, especially with AI these days. And so I've been just messing around with this. The one thing I've noticed is that you, whenever, there must be some kind of bug with Signal Messenger because it seems to lose the pipe wire set up on, at least on my computer. And I don't know, some weird thing with Signal, which hopefully DHH will figure out or somebody will. What I wanted is both, you know, things to basically coexist at the same time and not interfere with each other. And I wanted it to work with my old NVIDIA 1070 TI card, which I guess is Vulcan, as it turns out. So it took me a while to figure out how to get it to compile so that it would because lately, most of the distros have pushed all of the GPU code for NVIDIA into the 10, 5, you know, what is it, 580 stuff. And so then you kind of have to write, you know, maintain it separately as a separate, then what do you call it, like in Python, you kind of create a separate environment with a separate set of drivers. So anyways, that's what I've done. I'll see if I can share that with you too. It would be nice if, if it could figure that out. I don't think without the help of AI, I wouldn't have figured out how to recompile it. But, but, you know, this stuff is getting a lot smarter these days. Yeah, so then I press F 14.

You'll see it'll change to listening, has a similar little thing that's supposed to be moving, it's not as sensitive on this one. Um and uh it starts transcribing and eventually if I let go "

[peteonrails]

I'm not sure the problem you're having with Signal Messenger. Could you help me understand that a little bit better? I'm able to use VoxType to inject text into Signal Messenger's input box.

You had a question in here about using the GPU. There is a voxtype setup gpu --enable command that should link the Vulkan binary into place. You can check that it worked by using systemctl --user status voxtype. It should tell you if it loaded the Vulkan libraries in the output from that command.

I hope this helps!

[lukejmorrison]

/.config/voxtype/config.toml

config.toml.txt

/.config/hyprwhspr/config.json

config.json.txt

[peteonrails]

I think you want something different for your config.toml. Try this:

[hotkey]
# Disable built-in hotkey - using Hyprland keybindings instead
enabled = false

Then you can do this in your hyprland.conf:

# Voxtype push-to-talk keybindings
bind = , F14, exec, voxtype record start
bindr = , F14, exec, voxtype record stop

Interested to see how you implemented the live preview!

[lukejmorrison]

Peter, ok cool it seems to be working. Maybe a bit more responsive? The hotkey section should look like this?

[hotkey]
# Disable built-in hotkey - using Hyprland keybindings instead
enabled = false

# Voxtype push-to-talk keybindings located in hyprland.conf
# bind = , F14, exec, voxtype record start
# bindr = , F14, exec, voxtype record stop

key = "F14"
modifiers = []
mode = "toggle"  # Press once to start recording, again to stop

[peteonrails]

If you put enabled = false in the hotkey x=section, nothing else in that section matters. Voxtype instead will rely on the hyprland events.

[lukejmorrison]

Oh and one more thing I've been meaning to ask you. If I activate transcribe and say nothing and quickly press the button again. I often get the words "Thank you" I'm told that the thank you is something to do with open whisper or parakeet, but it's kind of weird. It doesn't happen on the um on the hyperwhspr, it only seems to happen on Voxtype. Yeah, anyway, kinda weird. Thought I'd ask. Maybe they've got some kind of code that um because it's kind of that the open whisper model is kind of thinking, so basically if you ask it to do something and you don't give it any input, it says thank you. I don't know, it's weird.

[peteonrails]

Possibly the model interpreting the audio cue? When I do the same thing, it transcribed "Boop Boop" !

[lukejmorrison]

Have you seen any of these other Local Open-Source Speech-to-Text Alternatives?

Executive Overview of Local Speech-to-Text Alternatives (Updated)

This overview summarizes key offline-capable speech-to-text (STT) tools suitable for high-accuracy local transcription, focusing on those that excel in handling large vocabularies, jargon, slang, and coding terms. All primary entries are open source and run fully locally on Linux setups like Omarchy, emphasizing compatibility with projects such as Voxtype (Rust-based push-to-talk STT for Wayland) or HyprWhspr (Hyprland-integrated STT). Based on the latest as of December 18, 2025, these tools are vetted for excellence (e.g., low WER on benchmarks like LibriSpeech/TED-LIUM, with fine-tuning support for domain-specific accuracy).

To keep your Omarchy install fresh, align with @dhh's recent posts on X—no new updates since December 15, 2025, so v3.2.3 remains the current release, with ongoing polish and community fixes. Run yay -Syu (or equivalent Omarchy-defined method per TROUBLESHOOTING.md) to update, and for any voice-related packages, use Omarchy-specific installers like omarchy-install-terminal if integrating terminals for testing.

Tool	Maker/Organization	License	Open Source	Free for Commercial/Open-Source Use	Key Notes on Licensing/Usage
Vosk	alphacep (independent open-source project)	Apache-2.0	Yes	Yes – Permits modification, distribution, and commercial use with attribution; no restrictions beyond retaining license notices.	Lightweight toolkit based on Kaldi; models downloadable for offline use. Ideal for embedded/Linux integration without viral clauses.
Whisper	OpenAI	MIT	Yes	Yes – Highly permissive; allows unrestricted commercial use, modification, and redistribution with minimal requirements (just include license).	End-to-end transformer model; pre-trained weights freely available. No royalties or limitations for commercial apps.
SpeechBrain	SpeechBrain (community-led, with international collaborators including academic institutions)	Apache-2.0	Yes	Yes – Free for commercial/open-source; modifications don't need to be open-sourced, but license headers must be retained.	PyTorch-based modular toolkit; supports custom recipes for fine-tuning on jargon/slang.
NVIDIA NeMo ASR	NVIDIA	Apache-2.0	Yes	Yes – Commercial use allowed; designed for researchers/developers, with no fees for integration into products.	Part of NeMo framework for multimodal AI; pre-trained models on Hugging Face/NGC are free under the same license.
Coqui STT	Coqui AI	MPL-2.0	Yes	Yes – Free for commercial/open-source; file-based copyleft requires source release for modifications to core files, but not for apps built on top.	Deep learning toolkit; no longer actively maintained (focus shifted to TTS), but stable releases remain usable.
Wav2Vec 2.0	Meta (formerly Facebook), hosted/maintained via Hugging Face Transformers	Apache-2.0	Yes	Yes – Fully permissive for commercial/open-source projects; models and library can be embedded without restrictions.	Self-supervised transformer models; integrated into Hugging Face ecosystem for easy access and fine-tuning.

All licenses are non-viral (except MPL-2.0's file-level copyleft for Coqui), making them suitable for inclusion in open-source projects like Voxtype/HyprWhspr without forcing your code to adopt the same terms. They support free redistribution of models/weights, enabling offline deployment on Omarchy without cloud ties. For installation on Omarchy, prioritize AUR/yay methods (e.g., yay -S python-vosk for Vosk) over standard Arch pacman, and check @dhh's X for any release notes on package compatibility—v3.2.3 includes tweaks for smoother AUR handling, with no updates since December 15, 2025.

Stack Ranking for Inclusion in Projects Like Voxtype or HyprWhspr

Ranking prioritizes: (1) Ease of integration into Rust-based Linux tools (native bindings > Python bridges via PyO3/subprocess); (2) Active maintenance and community support (for long-term Omarchy freshness); (3) Resource efficiency on typical PC hardware (CPU-friendly > GPU-heavy); (4) Out-of-box accuracy/robustness to jargon/slang/coding terms (via fine-tuning); (5) Overall alignment with Omarchy's lightweight, community-driven ethos per @dhh's updates. Higher ranks are better for quick prototyping and production use in Wayland/Hyprland environments.

1. Vosk – Top choice for Voxtype/HyprWhspr integration. Native Rust bindings simplify embedding without Python overhead; lightweight (CPU-only, real-time on modest hardware); active community with frequent model updates; excellent for custom vocab injection (e.g., coding jargon). Install on Omarchy: yay -S vosk-api vosk-model-en-us for English base.

2. Whisper – Strong for accuracy (best untuned handling of slang/jargon from massive training data); highly active with Hugging Face forks like faster-whisper for optimized local inference. Python-based, so integrate via subprocess or PyO3 in Rust; runs well on Omarchy with yay -S python-openai-whisper ffmpeg. Balances performance and ease.

3. Wav2Vec 2.0 – Close to Whisper in transformer-based accuracy/robustness; seamless Hugging Face integration for fine-tuning on tech slang. Python via Transformers library (yay -S python-transformers python-torch); good for modular swaps in HyprWhspr configs. Active ecosystem edges it over similar tools.

4. SpeechBrain – Modular and extensible for custom jargon models; solid accuracy with PyTorch efficiency. Community-driven maintenance aligns with Omarchy's polish (per @dhh's v3.2.3 notes). Python-only, requiring Rust-Python bridging; install: yay -S python-speechbrain.

5. NVIDIA NeMo ASR – High-end accuracy for technical speech; multilingual models shine on diverse slang. GPU-preferred (NVIDIA hardware needed for best perf), which may not suit all Omarchy setups; Python-based integration via subprocess. Active but hardware-tied; install: yay -S nvidia-nemo.

6. Coqui STT – Decent for lightweight inference with custom LMs for jargon; C++/Python bindings offer some Rust flexibility. Deprecated status (no updates since shift to TTS) drops it lower—risks compatibility issues on fresh Omarchy releases. Install: yay -S coqui-stt-git if needed for legacy.

For your setup, start with Vosk in Voxtype (edit src/transcribe.rs to use vosk-api crate) or HyprWhspr (fork and add Vosk backend). If accuracy trumps ease, swap to Whisper. Test on Omarchy v3.2.3 for stability, as @dhh noted community fixes in his December 15 post.

Addendum: Integration Potential of Microsoft Cognitive Services Speech SDK (Azure Speech SDK)

The Azure Speech SDK, developed by Microsoft, is a proprietary software development kit that exposes Azure AI Speech service capabilities for building speech-enabled applications, including speech-to-text (STT), text-to-speech, translation, and speaker recognition. It supports both real-time and batch processing using local devices, files, Azure Blob Storage, or streams, making it versatile for scenarios like dictation in tools such as VS Code's Speech extension.

• Core Features and Offline/Local Capabilities: While primarily cloud-oriented, the SDK enables offline processing in supported configurations (e.g., via embedded speech configs or containers for desktop/Linux). This allows local STT without constant internet, using downloaded models for recognition. However, initial setup often requires authentication with an Azure subscription, and full offline mode is limited—e.g., no true offline for mobile SDKs, and containers may need periodic Azure access for updates or auth. It's optimized for high accuracy in noisy environments, accents, and low-resource languages, with custom models for improving jargon/slang handling (e.g., coding terms like "async await").

• Licensing and Open-Source Status: Proprietary under Microsoft software license terms (not sold, licensed with reservations of rights; includes third-party notices). Not open source—the SDK core is closed, though sample code on GitHub (e.g., Azure-Samples/cognitive-services-speech-sdk) is MIT-licensed for demonstration. Free to use with an Azure account, but commercial redistribution requires compliance with Microsoft's terms, potentially including fees for high-volume usage via Azure pricing (e.g., pay-per-use for speech services).

• Supported Platforms and Integration Methods: Strong Linux support across languages like Python (via azure-cognitiveservices-speech), C++, Go, Java, C# (.NET Standard 2.0), and Node.js (NPM package: microsoft-cognitiveservices-speech-sdk). For Omarchy, install Python bindings with yay -S python-azure-cognitiveservices-speech (check AUR for availability, or use Omarchy-defined methods per TROUBLESHOOTING.md to avoid standard pip). Integration into open-source projects like Voxtype/HyprWhspr is feasible via Python/Rust bridges (e.g., subprocess calls) or native C++ bindings, with GitHub samples providing quickstarts for offline STT.

• Accuracy and Benchmarks: Excels in 2025 benchmarks (e.g., lowest WER in analyses from Medium and Soniox, outperforming many open-source options on accents/jargon). Custom speech models allow fine-tuning for domain-specific vocab (e.g., tech slang), achieving 95%+ accuracy in noisy or technical audio—better than untuned Vosk but comparable to fine-tuned Whisper.

• Suitability and Fit into the Mix: This SDK could complement the open-source alternatives as a high-accuracy proprietary option for users prioritizing performance over openness (e.g., hybrid setup in Voxtype: use Azure for jargon-heavy coding sessions, fallback to Vosk for lightweight tasks). It's reusable in commercial/open-source stacks if you accept the license, but its Azure dependency and closed nature may clash with Omarchy's community ethos—test offline viability first, as some features require cloud auth. For full integration, fork Voxtype/HyprWhspr and add conditional backends; install on Omarchy v3.2.3 via AUR/yay to stay fresh, aligning with @dhh's emphasis on polish in his December 15 post. If avoiding proprietary, stick to the ranked open-source tools.

[peteonrails]

Yes - voxtype uses Whisper. I chose not to use vosk

[lukejmorrison]

Have you seen this one being used in Goose AI called Faster Whisper? It looks cool too? Interesting:

### Faster Whisper Benchmarks (2025)

Faster Whisper (CTranslate2-optimized Whisper) excels in local STT, with 2025 benchmarks showing strong accuracy/speed trade-offs:

Accuracy (WER - Word Error Rate): Large-v3-turbo model achieves 7.7% WER on LibriSpeech (batched processing), outperforming base Whisper variants; distil-large-v3 at ~5-8% on English clean speech, robust to noise/accent/jargon (e.g., 95%+ on coding dictation per Reddit tests).

Speed: 6x faster than standard Whisper Large-v3 (e.g., transcribes 1-hour audio in 30 seconds on M3-Max or equivalent NVIDIA GPU); real-time (1x) on CPU for medium model, up to 10x with quantization.

Comparisons: Tops open-source charts (e.g., Northflank 2025 guide: 809M params for turbo, edges wav2vec2 on English tech audio); Modal benchmarks favor it for throughput vs. insanely-fast-whisper (hardware-intensive).

Resource: ~1-5GB RAM, CPU-viable but GPU boosts (e.g., CUDA on Omarchy: yay -S cuda if NVIDIA).

[peteonrails]

I have seen Faster Whisper, yes. It's not impossible to integrate into a Rust application, but it does complicate the user experience. I went with whisper for a few reasons, chiefly that 1) I use an AMD GPU and Faster Whisper is CUDA optimized and 2) because it's simpler and doesn't require users to transform models after downloading them.

[crmne]

This is awesome, great job! Hyprwhspr has tons of issues with mise. Voxtype solved them all!

[peteonrails]

This feedback makes my day! Thank you @crmne !

[crmne]

I wrote about it here: https://paolino.me/dictation-is-the-new-prompt/

[peteonrails]

@crmne I owe you a big "thank you" for this! (and also for Ruby LLM, which we're using at Tern.travel) Appreciate you!

[crmne]

Yay for the gift economy!

[goodroot]

Yes, there are Mise issues in hyprwhspr.

They have been resolved recently.

To be clear though, this is an issue with Omarchy: #2831

Many Python-based packages are broken.