Bitsum shipped Process Lasso 19.0 on 3 November 2026 and immediately made the interesting parts free. LatencyTest and Interrupt Affinity Policy (IRQControl) are now standalone tools that read the kernel’s own ETW events for ISR and DPC durations and let you pin device interrupts to specific cores. No new driver is installed. That is the right level of instrumentation for anyone whose real-time pipeline is still losing buffers on Windows.
Classic amplitude/frequency view. Actual capture graphs also include engine mixing, communications enhancements, and driver-induced jitter that no model can erase.
What LatencyTest actually measures
LatencyTest watches three things while you reproduce the problem:
- Per-driver ISR length (the code that runs at interrupt priority before anything else on that CPU can continue).
- Per-driver DPC length (the deferred work that follows).
- How long a real-time thread waits after the kernel has already marked it ready.
Thresholds are published: a single ISR or DPC ≥ 2 ms is “Bad”; thread wakes ≥ 3 ms more than a handful of times per minute also trip the verdict. The Spikes tab timestamps the worst events and names the driver. Copy Report dumps Markdown tables. Because it consumes the existing kernel trace providers, you can leave it running under a capture session without changing the path under test.
The partner tool, IRQControl, writes the interrupt affinity policy, priority, and MSI mode for a device. Windows reads those settings at device start. You can keep a GPU or NIC off the cores your audio or inference threads prefer, or force them onto the P-cores of a hybrid CPU. Original settings are saved so Restore All is a one-click rollback.
Why this still matters for local STT and overlays
Cloud STT endpoints keep posting sub-50 ms time-to-final numbers. Qwen3 ASR 1.7B variants have been measured around 35 ms TTFS on hosted infrastructure; Soniox STT RT v5 sits near 47 ms. Those numbers are real for the model once it has clean PCM. They are almost irrelevant once the samples have already been delayed or dropped inside the Windows audio engine.
A typical desktop capture path looks like this:
- WASAPI shared or exclusive mode, or a loopback client, pulls from the engine.
- The engine mixes, applies communications enhancements or spatial audio if enabled, and timestamps the buffer.
- Any long DPC on a core that the audio thread or the mixing engine needs will push the next buffer past the period. The client either gets a larger packet or an underrun.
- Your STT front-end (whisper.cpp, a GGUF ASR, or a Windows AI APIs experimental recognizer) only sees the late or incomplete frames.
A 2–3 ms DPC spike is enough to push a 10 ms buffer period into audible glitches or force the STT model to wait for the next stable partial. Speculative decoding or chunked models cannot recover samples that never arrived. Process affinity rules and ProBalance help with user-mode contention; they do not shorten an ISR that already owns the CPU.
Frequency/amplitude sketch. Real traces also show the device that owned the longest DPC.
Practical workflow
Start LatencyTest, leave it running, then open your capture or STT tool and speak. After a minute check the Drivers and Spikes tabs. Common offenders remain network adapters, USB audio interfaces, GPU drivers, and storage. Update the driver from the vendor (not Windows Update) first. If the same driver still dominates, open Interrupt Settings from the right-click menu and move its interrupts onto cores you are not using for the audio client or the local model.
On hybrid CPUs the default placement can land latency-critical interrupts on E-cores. Pinning them to a pair of P-cores is a common manual fix; IRQControl makes the policy persistent and reversible. Combine that with a CPU affinity or CPU Set rule for the STT process itself so the model threads stay off the same cores.
For measurement outside the GUI you can still fall back to older tools (xperf / Windows Performance Analyzer, LatencyMon) but the new free pair lowers the barrier enough that more people will actually look at the numbers before blaming the model or the language pack.
Trade-offs
Interrupt affinity is system-wide and applied at device start. A bad choice can make a device fail to initialize or increase latency for other workloads. Always keep the original settings. LatencyTest itself adds negligible overhead because it only consumes existing events, but remote desktop sessions and battery power plans inflate thread-wake numbers; the tool notes that.
None of this replaces a clean exclusive-mode WASAPI path or disabling the communications enhancements that inject extra processing. It simply makes the kernel-side contribution visible so you stop chasing model quantizations while a driver is still stealing 3 ms every few seconds.
Where local tooling still wins
Once the capture path is stable, the rest of the budget is ordinary: VAD or energy detection, chunk size versus latency, and whether you run a small local model or a BYOK endpoint. Tools that keep the audio entirely on-device and surface the raw buffer timestamps let you verify that the DPC work is actually gone. That is the layer Process Lasso’s new instruments finally make practical for anyone shipping a real-time Windows audio pipeline.
I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.
Top comments (0)