It hears the other side of the call too.

Most meeting tools pick a side. Note-taking apps that hook the Zoom SDK only ever see the meeting audio; transcribers that tap the mic only ever see you. MeetPing has to see both — the whole point is to ping when your name surfaces, and your name is mostly going to come out of someone else's mouth. Capturing both sides without a vendor SDK is the architectural tax we pay to stay app-agnostic.

The microphone side is the easy half. We open an AVAudioEngine input node against the system's default input device, tap it at 16 kHz mono (the rate Parakeet wants), and push frames into the streaming session. No file is written, no buffer survives longer than the rolling thirty-second window. If you switch from MacBook mic to AirPods mid-meeting, Core Audio fires a route-change notification and we reopen the tap against the new device without dropping a chunk.

ScreenCaptureKit, not the legacy loopback hacks

System audio on macOS used to mean installing a kernel extension or a virtual audio driver like BlackHole or Loopback and routing every app through it. That works, but it requires kext approval, a reboot, and one of the most obnoxious permission flows on the platform. Apple closed that gap in macOS 13 with ScreenCaptureKit — a first-party API that exposes system audio as a stream alongside screen frames, no kernel extension required. We create an SCStream configured to deliver only audio (no video frames at all), request the default audio output as the capture target, and push 16-bit PCM frames into the mixer.

The cost is one permission prompt the first time MeetPing arms: macOS asks the user to grant Screen Recording access, because ScreenCaptureKit lives under that TCC bucket even when no pixels are being captured. We mitigate the misleading-looking prompt by surfacing a clear explanation in the onboarding flow before macOS asks — most users grant it without thinking once they understand why.

Entitlements and Hardened Runtime

The app ships with Hardened Runtime on and is notarized. ScreenCaptureKit doesn't require a special entitlement — it's pure TCC — but our microphone tap does need com.apple.security.device.audio-input. Sandbox is off in v0.1 because the FluidAudio BNNS dylib loader can't live in a sandboxed process; this is documented entitlement-by-entitlement on the privacy posture page. Neither audio side ever leaves the MeetPing process — verifying with Little Snitch is part of every release build.

What happens when Screen Recording is denied

If the user clicks Don't Allow on the Screen Recording prompt, MeetPing degrades cleanly to mic-only mode rather than throwing a wall of errors. The listener still arms, the keyword scanner still runs, the popover still fires — you just won't get pinged on words the other side says. A soft banner in the popover header notes system audio off · click to grant so the state is visible without being naggy. The same applies to managed corporate Macs where IT has revoked the permission MDM-side: mic-only is the safe fallback, not a broken app.

Pair this with auto-arm and the listener stays cheap when nothing is happening — both taps close the second a meeting ends, so there is no background process holding the system audio handle while you scroll Slack.