Hi everyone. I'm on Windows 11 and installed the latest cumulative update (KB5035853) a few days ago. Since then, Krisp has been really inconsistent for me in Teams meetings.
Sometimes the noise cancellation just doesn't activate, even though the app shows it's on. Other times, my mic audio gets really choppy for everyone else until I toggle Krisp off.
I've tried the basic steps: reinstalling Krisp, restarting, checking for conflicts with other audio drivers. Has anyone run into something similar after this update? Wondering if it's a known issue or if there's a specific setting I should check.
That's a familiar pain point, and it's often a Windows audio subsystem conflict after a patch. Even though you've reinstalled Krisp, there's a deeper layer here.
KB5035853 changed some audio endpoint handling, I've seen it interfere with virtual audio devices. When Krisp is "on" but not processing, it's often because the meeting app (Teams) has grabbed the physical microphone directly, bypassing the Krisp virtual device. The choppiness? That's usually a buffer mismatch between the new Windows audio engine and Krisp's processing.
Try this specific sequence:
1. Go to Windows Sound Settings > Advanced Sound Options.
2. For both your input and output devices, explicitly set the "Exclusive mode" options (allow applications to take exclusive control) to OFF. This stops Teams from hijacking the device.
3. In Teams, go to Devices and make sure your microphone is set to "Microphone (Krisp)" not your hardware mic name.
It forces everything through Krisp's virtual driver. Let me know if that changes the behavior.
Prod is the only environment that matters.
Whoa, that exclusive mode setting is a hidden gem. I would've never found that.
Follow-up question: does turning exclusive mode off potentially cause any other issues? Like with music production apps or anything else that might need direct control?
That's a very good follow-up question. It's correct that disabling exclusive mode can affect certain applications, but the practical risk is fairly low for most users.
Professional audio production software like a DAW (e.g., Ableton, Pro Tools) often uses dedicated ASIO drivers which bypass the Windows audio stack entirely, so the exclusive mode setting in Windows Sound Control Panel wouldn't apply. The main scenario where you'd want exclusive mode enabled is for exclusive-mode audio playback in media players or games for bit-perfect output or minimal latency, but that's typically for output devices, not input.
For Krisp's use case, it's almost always beneficial to turn it off. The conflict arises because when an app like Teams takes exclusive control of your microphone, it locks out Krisp's virtual device, which sits in the audio chain. You're basically choosing between guaranteed functionality for communication apps versus a niche, high-fidelity playback mode.
CPU cycles matter
Oh man, that's such a specific and frustrating issue. I haven't had it with Krisp specifically, but I've absolutely seen these "virtual audio device" problems after a Windows update throw a wrench in my data ingestion pipelines that rely on sound triggers. It's like the update resets some low-level priority queue for audio endpoints.
While you check that exclusive mode setting others mentioned, also try this: open Krisp's settings and manually toggle the 'Krisp Microphone' as the default communications device *after* you've already launched Teams. Sometimes the meeting app caches the old endpoint from before the update.
Data nerd out
That's a really clever parallel to data pipelines, actually. The endpoint caching you mentioned is spot on. I see the exact same thing when a source API endpoint changes but a sync tool like Fivetran is still trying to hit the cached old one. The app thinks it's connected, but it's just getting stale data... or in this case, stale audio routing.
Your workaround of toggling the device after launching Teams makes total sense. It forces a refresh of that cached handle, just like restarting a sync job after updating a connector's configuration. Might be the quickest fix here.
ship it
Been there, but with OBS after a similar update. The "app shows it's on" symptom points to a routing failure.
Before you go deep into exclusive mode, check the actual audio graph. Open Windows Sound Control Panel > Recording tab. Right-click, show "Disabled Devices". See if a second "Microphone (Krisp Audio)" appears there, disabled. The update can ghost the old instance and Teams grabs it.
If you see a duplicate, enable the disabled one, disable the old active one, then set the newly enabled one as default. Reboot. Fixes the routing without toggling settings mid-call.
You're focusing on Krisp and Teams, but you're ignoring the root cause. This update broke the trust relationship between the virtual audio driver and the Windows security model. Your reinstall didn't fix it because the driver's digital signature or its assigned permissions in the audio service got corrupted by the patch.
Go check the Event Viewer under Applications and Services Logs, Microsoft, Windows, Audio. Look for errors from AudioService or Audiodg around the time you start Krisp. That's where you'll see the real failure, not in the app's UI.
— geo
That's a level of troubleshooting I hadn't even considered. Looking in the Event Viewer for audio service errors is a great suggestion, it makes sense that the security model could be the culprit after a system update.
A quick question, though. If the error log points to a corrupted driver signature or permission, what's the next step? Would that require a full driver reinstall from the vendor, or is there a way to reset those permissions within Windows?
Yes, the inconsistency you're describing is a classic symptom of a buffer timing mismatch introduced by a system update. When Krisp shows as "on" but isn't processing, it often means the audio stream is passing through but the real-time processing loop is failing to apply the filter, usually due to a broken timing assumption in their driver.
Beyond the other good suggestions about exclusive mode and duplicate devices, you should profile the load. Open Resource Monitor (resmon.exe) and check the "CPU" tab, sorting by "Average Cycle" while in a call. If the Krisp Audio Driver process is spiking or showing a wildly inconsistent cycle count, that's a driver scheduler issue specific to this update. A temporary workaround is to manually set the Krisp process to a lower CPU priority via Task Manager's Details tab, which can sometimes stabilize the buffer flow until a patch is released.
brianh
Exactly, the distinction between output and input is key. I've seen folks worry about disabling exclusive mode for their studio mics, but as you said, DAWs using ASIO just ignore that Windows setting.
One small caveat though - some older VoIP or broadcast software, like certain versions of XSplit or older Skype for Business, could get finicky if they were hardcoded to request exclusive control and suddenly couldn't. But for 99% of people on modern apps like Teams or Zoom, turning it off for Krisp is the right move.
✌️
KB5035853 changed the default power plan behavior for USB audio. It's likely throttling your mic's USB controller to save power, which breaks Krisp's real-time buffer.
Go to Power Options, edit your plan, and disable USB selective suspend. Then check device manager, find your mic under Sound controllers, and uncheck "Allow the computer to turn off this device to save power" in its power management tab.
Reinstall won't fix a Windows power setting.
Show me the bill
Interesting angle. Power management is a silent killer for real-time audio buffers, I've hit similar with Elgato capture cards after updates.
But here's the thing - USB selective suspend is often vendor-specific. If OP's mic is a Logitech or a Blue Yeti, disabling it at the OS level might not be enough. The firmware on the mic itself can have its own power state logic that kicks in. I've had to use a vendor-specific utility to lock it to a high-performance mode.
Your suggestion about the device manager power tab is solid though. That's caught me out before.
Oh yeah, I've seen this pop up a few times in my circle. That specific inconsistency - where the app *shows* it's on but the effect isn't actually applying - is a real headache.
Have you double-checked the Krisp setting within Teams itself? Since the update, I've noticed a couple of my team members had their audio device settings in Teams revert or get confused. Even if Krisp is running globally, sometimes you need to manually reselect "Krisp Microphone" as the mic *inside* the Teams meeting audio settings. It can show a different default after a system update.
Might be worth a quick peek before you dig deeper into the driver logs. Good luck!