Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] Windows 0.0.9: activation latency grows from 220 ms to 6+ s over multi-day uptime (memory grows to ~3.9 GB); restart fully resets

Open
  • Is something wrong?
#917 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
swift
Domain
performance

Research direction

Start by tracing the recorder startup and overlay-show paths corresponding to start_request_to_recorder_ready_ms and start_request_to_recording_overlay_visible_ms in the reported fluidvoice.log excerpt. Compare those timings and memory use after a fresh launch and after extended uptime using the listed Windows 0.0.9 reproduction steps. Done means identifying and fixing the cause so activation latency and memory remain stable during multi-day use.

Written by the indexing model from the issue text.

Description

bug keep-open windows
Describe the bug

FluidVoice Windows 0.0.9 degrades over multi-day uptime. After ~4 days running continuously, the process working set had grown to 3.9 GB (private bytes ~3.0 GB) and every dictation activation stalled for seconds before recording started. Because the recording overlay waits on the recorder, the overlay also appears seconds late (or seemingly not at all if the user releases the hold-mode shortcut first). A restart of the app fully resets both memory and latency, with no other changes to the system.

Reproduction steps
  1. Install FluidVoice Windows 0.0.9, Parakeet v3 q8 model ("Blazing Fast - Multilingual", parakeet.cpp/c-api, CPU), hold activation mode, Ctrl+Win shortcut.
  2. Leave the app running for several days of normal daily dictation use (no reboots).
  3. Press the shortcut and observe the delay before the overlay/recording starts.
  4. Restart the app and repeat — latency returns to normal immediately.
Expected behavior

Activation latency stays roughly constant regardless of app uptime; memory stays near the fresh-launch footprint plus the loaded model.

Actual behavior

App-reported dictation_performance metrics from fluidvoice.log on the same machine, same version, same model:

Metric Fresh launch After ~4 days uptime
start_request_to_recorder_ready_ms 220 6,025
start_request_to_recording_overlay_visible_ms 4 4,458
transcribe_ms 231 (4.4 s audio) 1,079 (20.7 s audio)
Process working set ~43 MB at launch (before model load) 3,959 MB

Transcription itself stays fast; the regression is entirely in activation/recorder startup.

Log excerpt from the degraded state — note the process logs nothing at all for 4.4 s between the overlay show event and the overlay becoming visible (looks like an internal stall, not an audio-device wait):

14:16:32.820 [INFO] Starting recording: device=System default, max_seconds=unlimited, ...
14:16:32.820 [INFO] Overlay show requested: state=recording
14:16:32.821 [INFO] Overlay positioned: x=3330.0, y=1216.0
14:16:32.821 [INFO] Overlay show-overlay event emitted: state=recording
        <-- no log output for 4.4 seconds -->
14:16:37.277 [INFO] Overlay window shown without activation
14:16:37.278 [INFO] Overlay visible: state=recording, show_ms=4457
App Version

Windows 0.0.9 (windows-v0.0.9)

Environment
  • Windows 11 Pro 10.0.26200, x64, 128 GB RAM (system otherwise healthy when measured: 69 GB free RAM, ~25% CPU)
  • Model: Parakeet TDT 0.6b v3 q8 GGUF, CPU inference
  • Activation mode: hold; AI enhancement globally enabled but not used in these dictations (fi_requested: false)
Workaround

A scheduled nightly restart of the app fully mitigates it.

(Reported with the help of Claude, which gathered the metrics from fluidvoice.log on the affected machine.)

Dominant language
Swift
Stars
11.9k
Forks
863
Avg merge
1d 13h
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from altic-dev/FluidVoice

All issues in altic-dev/FluidVoice

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.