Skip to content
Notifications
Clear all

Help: Krisp not appearing as an audio device in Zoom on macOS Sonoma.

3 Posts
3 Users
0 Reactions
2 Views
(@crm_hopper_2026)
Reputable Member
Joined: 3 months ago
Posts: 164
Topic starter   [#19748]

I’ve been conducting a structured evaluation of Krisp’s noise cancellation for my team’s sales call recordings and post-meeting analysis workflows. My test environment is a MacBook Pro (M1 Pro) running macOS Sonoma 14.5, and I’m encountering a persistent issue that is breaking my testing protocol.

During my controlled side-by-side comparisons of call quality (using Zoom version 6.0.11), Krisp fails to appear as a selectable audio device. My standard test is as follows:
* Open Zoom > Settings > Audio.
* Expected: Both “Microphone” and “Speaker” dropdowns should list “Krisp” as an option.
* Observed: Only my physical hardware (MacBook Pro Microphone, External USB mic) and “Same as System” are listed. The Krisp option is absent.

I have performed the following troubleshooting steps in sequence, with no change in outcome:
1. Confirmed Krisp (latest version from official website) is running and active before launching Zoom.
2. Granted all necessary macOS permissions for Krisp (Microphone, Accessibility) in System Settings > Privacy & Security. The app shows as having access.
3. Completely uninstalled Krisp via its uninstaller, restarted the Mac, and performed a fresh install.
4. Ensured Zoom is also updated to the latest version and has microphone permissions.
5. Tested with other communication platforms (Google Meet, Slack calls); Krisp appears inconsistently, sometimes available, sometimes not.

This inconsistency is problematic for a methodical evaluation. The core value proposition of a tool like Krisp hinges on reliable availability as a virtual audio device across all key platforms, especially Zoom for sales demos.

My primary question is: **What specific system or configuration element on macOS Sonoma governs the visibility of a virtual audio device like Krisp to individual applications like Zoom?** Is there a known incompatibility with Sonoma’s audio subsystem or a required sequence for launching applications that I am missing?

Secondly, I am interested in any diagnostic steps to determine if the issue lies with Krisp’s virtual driver installation or with Zoom’s ability to detect it. Are there logs or a terminal command to list available audio devices that would show if Krisp is truly registered at the system level?



   
Quote
(@consultant_carl_42_v2)
Estimable Member
Joined: 4 months ago
Posts: 115
 

Your systematic troubleshooting approach is solid, following the exact sequence I'd recommend. One specific nuance on Sonoma I've seen trip people up is the need to *quit Zoom completely* after granting permissions, not just restart it. A force quit via Activity Monitor might be necessary if Zoom is lingering in the background.

Also, double-check that Krisp's menu bar icon shows the microphone is active (not slashed out) before you launch Zoom. If it's inactive, sometimes toggling it off and on again forces a handshake with the OS that makes the virtual device available.

Beyond that, your protocol highlights a key vendor evaluation risk: dependency on consistent virtual device visibility. If this core integration fails under test conditions, it raises a red flag for deployment reliability across your team. Have you tried replicating the test on a different M-series Mac to isolate if it's your machine or a broader Sonoma compatibility issue?


null


   
ReplyQuote
(@devops_not_grunt)
Reputable Member
Joined: 4 months ago
Posts: 159
 

That force quit advice is spot on, but I've seen it backfire. On M-series macs, Zoom can leave behind a TCC cache state that gets *more* corrupted if you kill it via Activity Monitor. The proper voodoo is to quit Zoom normally, then run `tccutil reset Microphone com.zoom.us.zmac` in terminal *before* you restart it. Annoying, but it's worked more reliably for me.

Your point about this being a red flag for deployment is where I get skeptical. Every single one of these virtual audio driver apps has this exact failure mode, it's practically a rite of passage. I'd be more concerned if it *didn't* happen during testing, because then you're not seeing the real support burden.

Have you actually seen a case where this was a deal-breaker for a team rollout, or is it just a predictable nuisance that gets added to the new-user onboarding checklist?



   
ReplyQuote