Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Dictation loses the first ~0.7 s of speech when the mic has been idle
Reported by kenners22 · filed Oct 3, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Dell XPS 14 (2026, Intel Lunar Lake, SOF SoundWire mic: cs42l45), Omarchy 4.0.4, voxtype-bin 1.1.0, default default/voxtype/config.toml
What's wrong?
With Omarchy's default dictation setup, the first ~0.7 s of every dictation is silently lost whenever the mic has been idle for more than 5 s, so the first word or two goes missing.
PipeWire suspends the idle mic source after 5 s, and the audio DSP powers down 2 s after that. When voxtype record start runs (F9 or Super+Ctrl+X), voxtype counts the recording as started at once, but audio only arrives once the source has woken up:
Recording stopped (2.4s) Transcribing 1.7s of audio...
Recording stopped (13.2s) Transcribing 12.5s of audio...
Recording stopped (2.2s) Transcribing 1.5s of audio...Same 2 s test with the source already running: Transcribing 2.0s. About 0.2 s of the gap is the DSP resuming and about 0.5 s is the codec's capture path starting. There's no ALSA control to shorten it on this hardware.
It's also why the dictation overlay takes ~0.7 s to appear: voxtype's default GTK4 OSD only shows when the first audio frame arrives. Switching the default to the Quickshell OSD would make the overlay appear instantly (I measured ~20 ms), but people would then start talking before the mic is listening, which makes this worse. So I've left that alone.
Reported upstream with details: https://github.com/peteonrails/voxtype/issues/817
Steps:
1. Leave the mic idle for 10 s (pactl list sources short shows it SUSPENDED).
2. Hold F9, say a sentence straight away, release.
3. The first word or two is missing. The voxtype log shows the captured audio ~0.7 s shorter than the recording.
Possible fixes on the Omarchy side, if wanted before voxtype handles it: a WirePlumber rule that keeps the internal mic awake while voxtype is installed (fixes it, costs some battery), or a line in the manual's dictation section: "pause a moment after pressing F9 before speaking".
View raw text
### System details Dell XPS 14 (2026, Intel Lunar Lake, SOF SoundWire mic: cs42l45), Omarchy 4.0.4, voxtype-bin 1.1.0, default `default/voxtype/config.toml` ### What's wrong? With Omarchy's default dictation setup, the first ~0.7 s of every dictation is silently lost whenever the mic has been idle for more than 5 s, so the first word or two goes missing. PipeWire suspends the idle mic source after 5 s, and the audio DSP powers down 2 s after that. When `voxtype record start` runs (F9 or Super+Ctrl+X), voxtype counts the recording as started at once, but audio only arrives once the source has woken up: ``` Recording stopped (2.4s) Transcribing 1.7s of audio... Recording stopped (13.2s) Transcribing 12.5s of audio... Recording stopped (2.2s) Transcribing 1.5s of audio... ``` Same 2 s test with the source already running: `Transcribing 2.0s`. About 0.2 s of the gap is the DSP resuming and about 0.5 s is the codec's capture path starting. There's no ALSA control to shorten it on this hardware. It's also why the dictation overlay takes ~0.7 s to appear: voxtype's default GTK4 OSD only shows when the first audio frame arrives. Switching the default to the Quickshell OSD would make the overlay appear instantly (I measured ~20 ms), but people would then start talking before the mic is listening, which makes this worse. So I've left that alone. Reported upstream with details: https://github.com/peteonrails/voxtype/issues/817 Steps: 1. Leave the mic idle for 10 s (`pactl list sources short` shows it `SUSPENDED`). 2. Hold F9, say a sentence straight away, release. 3. The first word or two is missing. The voxtype log shows the captured audio ~0.7 s shorter than the recording. Possible fixes on the Omarchy side, if wanted before voxtype handles it: a WirePlumber rule that keeps the internal mic awake while voxtype is installed (fixes it, costs some battery), or a line in the manual's dictation section: "pause a moment after pressing F9 before speaking".
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 21:03 UTC