We’re integrating Krisp noise cancellation via the useKrispNoiseFilter hook from @livekit/components-react/krisp in our desktop application. We’re experiencing an issue where the Krisp processor randomly enters an unrecoverable error state during normal use.
At seemingly random intervals, across multiple machines, the Krisp noise filter processor fails internally. When this happens setNoiseFilterEnabled() begins throwing WORKLET_NOT_SUPPORTEDerrors, with the underlying Krisp SDK reporting DOMException: The user aborted a request. during createNoiseFilter.
Krisp hook: error enabling filter Error: WORKLET_NOT_SUPPORTED
at y2.createNoiseFilter
at async UI.connect
at async JE.init
KrispSDK - KrispSDK:createNoiseFilter DOMException: The user aborted a request.
The processor never recovers from this state, the only resolution is a full app restart. This is a blocker for production since we have not been able to identify a reliable reproduction pattern. It happens randomly during normal usage across different machines.
Has anyone else encountered this? Any known workarounds?
// To enable/disable the noise filter, use setEnabled()
await krispProcessor.setEnabled(true);
// To check the current status use:
// krispProcessor.isEnabled()
// To stop and dispose of the Krisp processor, simply call:
// await trackPublication.track.stopProcessor()
}
^ those lines are commented out, but I wonder if there is something in your framework recreating the processor without stopping it. Just a guess.
Thanks for looking into this. We removed our direct stopProcessor() call and now the code relies entirely on the useKrispNoiseFilter hook from @livekit/components-react/krisp to manage the processor lifecycle.
Our component now only calls setNoiseFilterEnabled() from the hook’s return value, we never touch the processor directly.
After testing with this simplified implementation, the issue still occurs, same WORKLET_NOT_SUPPORTED error followed by KrispSDK:createNoiseFilter DOMException: The user aborted a request., same unrecoverable state.
Since we’re not creating, stopping, or disposing the processor ourselves, the teardown/recreation issue would have to be happening internally within the hook or the Krisp SDK itself.
In the browser/Electron frontend, Krisp runs as an AudioWorklet and downloads models at runtime. If the worklet fails to initialize, you can see WORKLET_NOT_SUPPORTED, and createNoiseFilter may surface DOMException: The user aborted a request. This typically indicates the AudioWorklet environment was torn down or became invalid, not just a hook lifecycle issue.
Two things to verify:
Call isKrispNoiseFilterSupported() before enabling, as noted in the frontend section of Noise & echo cancellation.
Ensure the microphone track (and underlying AudioContext) is not being restarted or replaced by Electron (e.g., device changes, permission resets, hidden window suspension), which would invalidate the worklet.
Since this is Electron-specific, are you recreating the Room, switching audio devices, or suspending the window when this happens?
isKrispNoiseFilterSupported() : The useKrispNoiseFilter hook already calls this internally before creating the processor, so this is covered.
Room recreation: No, the Room is created once and stays connected.
Audio device switching: Users can switch audio input devices during a session via LiveKit’s setActiveMediaDevice(). But we have not observed any issues with this so far.
Window suspension: We have backgroundThrottling: false set on electron’s BrowserWindow. None of the users who encountered this were using battery savers, if that’s relevant.
OS: I forgot to mention this, the issue has only been observed on windows so far. We haven’t tested on macOS or linux yet.
Anyway, I was able to witness the issue trigger in real time. It happened immediately upon connecting to a room, as soon as krisp initialized the console got flooded with the WORKLET_NOT_SUPPORTED / DOMException: The user aborted a request. errors. This suggests the initial setNoiseFilterEnabled() call can fail right from the start, not only after some time in the room. We’ve also seen it happen while already connected, so it’s possible the same thing occurs on reconnection if the hook re-initializes.
Regardless of the root cause, i think the broader issue is that the processor can enter a permanently broken state with no recovery path. If the AudioWorklet context becomes invalid for any reason (during initial setup, device change, reconnection, or something else) the hook or sdk should either recover internally.
Yes, sorry about that I did post in the wrong thread. I will check with our experts on this electron issues as it is a ways outside of my area of expertise and see if they have any ideas about what might be happening here.
