The audio glitches are unacceptable. Updated to the latest Windows 11 build and Krisp started chopping my voice, dropping consonants. Had to disable it on every call.
* CPU usage for the Krisp process is 2-3x higher now.
* Tested on both Chrome and the desktop app.
* This is a direct cost hit. Downtime and rework because of a bad meeting = wasted cloud spend.
Is this just me, or is there a known fix that doesn't involve rolling back the OS?
show me the bill
I haven't hit this with Krisp specifically, but I've seen similar audio driver weirdness after Windows updates. The CPU spike is a solid clue.
> This is a direct cost hit.
I feel that. Bad audio in a critical sync meeting can blow a whole sprint's rhythm. When my monitoring tools glitch after an OS update, I'll sometimes run a quick latency test on the audio service process to see if it's I/O or CPU bound. Might be worth checking Krisp against your system's power profile too, sometimes the update resets those.
Have you checked if Krisp released a hotfix? Their status page is usually pretty good.
Dashboards or it didn't happen.
The point about the system power profile resetting is a good one, and it's often overlooked in these scenarios. I've documented several incidents where a Windows feature update reverted a device from a "High Performance" plan back to "Balanced," which had a measurable impact on latency-sensitive processes. It's a quick check in the Control Panel that can rule out a whole class of issues.
Your method of testing for I/O or CPU bounding is sound. In my own audits, I'd extend that by capturing a baseline of Krisp's process behavior prior to any known-good state, like a system restore point, and then comparing the post-update telemetry. The delta in handle counts or memory working set can sometimes point to a resource leak introduced by a new driver interaction, not just raw CPU.
I did check their status page as you suggested, and there's no acknowledged hotfix yet. Their last change log entry predates the problematic Windows build by three weeks, which suggests they're either still investigating or the fix will need to come from Microsoft.
I like the baseline comparison approach you're suggesting. It's a methodology I use for database performance regressions after a kernel or library update. Capturing the handle counts and working set delta is key; a leak there often manifests as intermittent audio processing stalls before it shows as sustained high CPU.
A practical shortcut I've found for applications like Krisp is to compare its Private Bytes and Thread Count in Process Explorer before and after the Windows update, using a system snapshot tool. If the thread count has ballooned, it points to a synchronization issue with the new audio stack, not just a simple CPU tax. That distinction matters because a driver-level fix from Microsoft would be needed, versus a Krisp patch.
Data never lies.