Better voice-to-text dictation default?

[LeonardoTrapani]

I see omarchy has voxtype as the default for dictation.

I built hyprvoice and it's actually been around for more than Voxtype, but I finally released 1.0

It has a lot of extra features, both local and cloud models, fully configurable and in built specifically for hyprland and omarchy.

I've tried Voxtype for a while and it was never too good, and Hyprvoice atually feels like whisprflow if anybody has tried it.

We have llm post processing, fully configurable from which models to use to the recording buffer size, keywords and custom prompt to make it better, and a LOT of models.

Any reason why you would stick to Voxtype? Anything I could improve in hyprvoice?

Here is the link if interested: hyprvoice

PS: re-reading it sounds like I'm trying to sell it, but I'm genuinely interested to know which features I could support that would make it get into Omarchy!

[pomartel]

For me the killing feature would be real-time dictation like in iOS. The text appear as you talk and you can edit it live with the keyboard. I think there is an Open AI model that uses websockets that could be used for that but there might be limitations with wayland.

Other than that, there's a lot of voice-to-text solutions out there and they all work more or less the same.

[LeonardoTrapani]

For me the killing feature would be real-time dictation like in iOS. The text appear as you talk and you can edit it live with the keyboard. I think there is an Open AI model that uses websockets that could be used for that but there might be limitations with wayland.

Other than that, there's a lot of voice-to-text solutions out there and they all work more or less the same.

We arrleady have a lot of streaming models implemented! We just don't support injection of the text in streaming but only once it's completed for things like changing window and stuff, but we could work on that.

Anyway for voice-to-text right now I don't agree that they are more or less the same, most of them are just Take voice -> Voice model -> inject, we have way more, like llm processing and more, which is what makes it actually different

[peteonrails]

@pomartel Streaming output will be in voxtype 0.7.1.

[pomartel]

@peteonrails Awesome! I'm eager to try it.

[goodroot]

Hyprwhspr supports multiple local models natively (parakeet & faster-whisper), has a visualizer, and a flexible API that supports any cloud model. There's also audio ducking, record-and-save for long-form recordings, keys to drop models in/out of VRAM, and a whole lot of other configs. You're welcome to steal whatever.

[LeonardoTrapani]

Hyprwhspr supports multiple local models natively, has a visualizer, and a flexible API that supports any cloud model. There's also audio ducking, and keys to drop models in/out of VRAM. You're welcome to steal whatever.

We have basically all that as well, 26 models, on onboarding and config tui, cloud, locals, fully configured, and way more!

Love the project tho

[LeonardoTrapani]

Asked Claude to diff the projects for both features/architecture:

Feature hyprvoice hyprwhspr
Language Go Python
Recording modes Toggle Toggle, push-to-talk, auto tap/hold, long-form
Local backends whisper-cpp pywhispercpp, faster-whisper, onnx-asr (Parakeet)
Cloud STT providers OpenAI, Groq, Mistral, ElevenLabs, Deepgram OpenAI, Groq, Regolo, ElevenLabs, custom REST
Streaming/realtime OpenAI, ElevenLabs, Deepgram OpenAI Realtime, ElevenLabs Scribe v2
LLM post-processing Yes — grammar, punctuation, stutter/filler removal Depends on model
Keyword hints Yes (sent to voice model + LLM) Word overrides dict + filler word filtering
Symbol replacements No Yes ("period" → ".")
Secondary language hotkey No Yes — separate shortcut with language override
Text injection wtype → ydotool → clipboard (auto-fallback) ydotool, wtype, clipboard; multiple paste keystrokes
Kitty protocol support No Yes — detects and uses direct injection
Non-QWERTY support No Yes — custom keycodes via wev/evdev
Auto-submit (Enter after paste) No Yes (optional)
Audio visualizer No Yes — GTK4 mic-OSD with VU meter/waveform
Audio ducking No Yes — reduces system volume during recording
Audio feedback (beeps) No Yes — custom OGG/WAV/MP3 supported
Waybar integration No Yes — status tray with click-to-control
GPU memory management N/A Yes — unload/reload model without stopping service
Mute detection No Yes
USB hotplug recovery No Yes — pyudev-based with retry thread
Suspend/resume recovery No Yes — CUDA context invalidation detection
Hot config reload Yes — fsnotify, no restart needed No — service restart required
Config format TOML JSON (with schema for IDE support)
API key storage Config file + env vars Separate credentials.json
Model count 26 named models Varies by backend (fewer named, more backend variety)
Onboarding/setup hyprvoice onboarding + TUI hyprwhspr setup (auto-detects GPU)
Distribution AUR only AUR + multi-distro installer script
Testing Go unit tests + test-models E2E command hyprwhspr test + hyprwhspr validate
Architectural Trade-offs

Dimension hyprvoice hyprwhspr
Architecture style Daemon + IPC socket; clean interface-based pipeline Long-lived systemd service; thread-per-subsystem
State machine Explicit: idle → recording → transcribing → processing → injecting Lock-based: multiple mutexes guard concurrent state
IPC protocol Unix socket, single-char commands (t, c, s, q) Filesystem signals + named FIFO
Concurrency model Go channels + goroutines; context cancellation throughout Python threads + locks; recovery retry thread
Testability High — factory-based DI, interfaces everywhere, CI unit tests Lower — no automated suite, manual/E2E only
Extensibility Add a provider = implement BatchAdapter/StreamingAdapter interface Add a backend = extend whisper_manager dispatch; less structured
Local model memory Loads model per-transcription (whisper-cpp subprocess) Keeps model hot in memory; unload/reload on demand
Audio capture Shells out to pw-record (external process) sounddevice in-process; real-time level monitoring
Config reload Live via fsnotify — zero downtime Requires full service restart
GPU support None First-class — auto-detects CUDA/Vulkan at setup
UI/UX surface Lean — notifications only Rich — OSD visualizer, beeps, ducking, Waybar tray
Recovery complexity Minimal — relies on clean restarts High — USB, suspend, muted mic all handled in-process
Binary size / deps Single Go binary, minimal runtime deps Python venv with many packages (numpy, scipy, evdev, gtk…)
Startup time Fast — compiled binary, daemon already running Slower — Python interpreter + model warm-up
Best fit Cloud-first, LLM-enhanced, clean codebase, easy to hack Local-first, feature-rich UX, handles messy real-world Linux hardware

Love it!

I'd summarize with:

better quality / post transcription / keywords (wisprflow like): hyprvoice
better integrated in the linux ecosystem: hyprwhispr
easier to extend: hyprvoice
local first: hyprwhispr
cloud first: hyprvoice
more ux features: hyprwhispr

[CurePortal]

I prefer WHIS

https://github.com/frankdierolf/whis