Commit graph

3 commits

Author SHA1 Message Date
Doxa Maps
c067a5d069 Dictation fell behind because our own build took every core
Rudder was measured slowing after about 1,400 words while a Tauri build
ran. The word count is incidental — it is a proxy for how long the build had
been going. The speech model runs on the CPU (backend/rudder-engine starts it
with --device cpu), and a Rust build saturates every core, so at equal priority
it starves the one process whose latency a person can hear.

Three changes, and the direction of the first is forced rather than chosen:

1. internal/desktop-build.mjs nices the whole build tree to 10, through the one
   run() helper every step goes through, so cargo, rustc and the linker inherit
   it. We nice the COMPETITOR because an unprivileged process cannot raise its
   own priority on Linux — a negative nice needs CAP_SYS_NICE — so "promote the
   ASR" would fail with EPERM. If nice(1) is missing the build still runs and
   says so, because a silent fallback would look exactly like the fix working.

2. cargo is capped at cores-1. nice decides who wins a CONTESTED core; it does
   not stop the build taking all of them, and a fully subscribed machine still
   adds scheduling latency to the audio path. An explicit CARGO_BUILD_JOBS is
   honoured rather than overridden.

3. yieldCPU reports its error instead of discarding it. It was
   `_ = syscall.Setpriority(...)`, which cannot fail visibly — a call that
   silently does nothing is indistinguishable from one that worked, and this one
   guards something audible.

Also, one real O(n) in the widget, found while checking studio's answer that the
collapsed pill already shows the last words: sendActivity split the ENTIRE draft
on every activity tick to take five words. Measured at 3,000 words: 1.61ms per
tick against 0.051ms for a bounded tail, 31x, with byte-identical output.

Verify the priority work with `ps -o ni=` on the running cargo processes, never
by any of these calls returning.
2026-09-29 05:26:25 +00:00
Doxa Maps
2bff270734 Rudder keeps streaming on a thin client: reconnect a broken speech stream, say when it falls behind
Some checks are pending
Deploy to GitHub Pages / build (push) Waiting to run
Deploy to GitHub Pages / deploy (push) Blocked by required conditions
Optimising the default for an average laptop, not more CPU (the speech model is hard-wired to 4 threads in
NeMo-Speech.cpp, session.cpp:911 — already a thin-client budget).

- RECONNECT: a live recording ended with "speech server connection lost: … broken pipe" when the stream to
  the speech server broke. Now the engine opens a new stream and keeps going; the words still in flight on
  the old one are finalised so the box keeps them; up to 5 attempts, then a plain message. Verified against
  a fake speech server that drops the first stream after 3 s: 6 words finalised, reconnected in 2 ms, 14 more
  words streamed, clean Stop, 0 data races (go -race).
- FALLING BEHIND: when the mic clearly carries speech but no words have come back for 10 s (the server is
  starved of CPU — the stream used to freeze with no message), say so once; it clears when words resume.
  Verified with a fake server that returns no words: warned after 10 s.
- The robot voice (Piper) runs at nice 10 on Linux, so its ~1 s burst per sentence never makes the words
  you are speaking fall behind.
2026-09-28 15:31:19 +00:00
Doxa Maps
ea151b9a56 rudder-engine builds for macOS and Windows, finds its runtime per platform, and accepts the desktop webview's stream
The engine did not compile outside Linux: Pdeathsig (kill children with the
engine) is Linux-only. It now sits behind a build tag, with a no-op elsewhere
where the desktop shell owns the engine's lifetime. The default speech-server path
names this platform's NeMo-Speech.cpp release folder instead of the Linux one.
The /stream WebSocket accepts the Tauri origins (tauri://localhost,
http://tauri.localhost) and RUDDER_ALLOW_ORIGIN as well as the page's own host,
and still refuses any other site. Cross-compiled for darwin/arm64, darwin/amd64
and windows/amd64.
2026-09-28 02:38:49 +00:00