Virtual Cameras & Microphones

Open Zoom's device menu and you might see cameras that don't exist — no lens, no cable, no glass. A virtual camera is software wearing a hardware costume, and the trick behind it is one of the most useful ideas in desktop media: if you can convince the operating system you're a device, every app in the world supports you automatically.

The idea: software that looks like hardware

Every operating system draws a line between applications and devices. Apps that want video don't talk to USB cables; they ask the OS for a list of cameras and pull frames from whichever one the user picks. The same goes for microphones and audio samples. That indirection creates an opening: anything that registers itself on the device side of the line becomes, as far as every application is concerned, real hardware.

A virtual camera is exactly that — a device driver with no device behind it. Instead of reading a sensor, it serves frames that some other program generated: a composited scene, a processed webcam feed, a screen capture, a rendered avatar. A virtual microphone does the same with audio buffers. The payoff is enormous leverage. There is no Zoom plug-in to write, no Meet integration to maintain, no Teams SDK to chase. The conferencing app just enumerates devices, the virtual one appears alphabetically in the list, and the user selects it. One implementation, universal compatibility — including with apps that won't exist for years.

How it used to work on macOS: DAL plug-ins

For years, the macOS mechanism for this was the CoreMediaIO DAL plug-in — DAL for Device Abstraction Layer. A DAL plug-in was a bundle installed in a shared system location; any application that used the camera APIs would load every installed plug-in into its own process, and each plug-in could then announce whatever devices it liked. Early virtual cameras on the Mac — streaming tools, conferencing helpers, OBS's original virtual camera — all worked this way.

The design had a structural flaw: it was arbitrary code injection by convention. Loading a DAL plug-in meant executing third-party code inside every camera-using app on the system — your browser, your bank's video-KYC page, FaceTime. A buggy plug-in could crash them all; a malicious one ran with each app's privileges and could see each app's memory. Security-conscious apps responded by refusing to load plug-ins that weren't signed by their own developer, which "fixed" the risk by quietly breaking virtual cameras in the very apps people wanted them in. The mechanism was fundamentally at odds with the direction of macOS security.

The modern mechanism: CoreMediaIO Camera Extensions

Apple resolved the tension in macOS 12.3, deprecating DAL plug-ins and introducing CoreMediaIO Camera Extensions as their replacement. The differences are architectural, not cosmetic. A camera extension is a system extension: it ships inside a signed, notarized app, must be explicitly approved by the user in System Settings before it can activate, and runs in its own sandboxed process managed by the system — not inside the apps that use the camera. Client apps never load the extension's code. They talk to the virtual device through the same OS-mediated path they'd use for a physical webcam, and frames cross the process boundary as data, not as executable code.

This flips the trust model. Under DAL, every camera app had to trust every installed plug-in. Under Camera Extensions, the user grants trust once, to a specific signed extension, and the blast radius of a bug is one sandboxed process the system can restart. It costs the developer real friction — entitlements, notarization, an install-time approval step — in exchange for a virtual camera that works in hardened apps precisely because it never enters them. The extension keeps running independently of the app that installed it, publishing its device to the system for as long as it's enabled; the companion app's job shifts to feeding it frames and configuration across a well-defined boundary.

The audio side: Core Audio HAL drivers

Virtual microphones follow a parallel but older path. Core Audio, the Mac's audio subsystem, has long supported user-space driver plug-ins loaded by its Hardware Abstraction Layer — bundles installed in /Library/Audio/Plug-Ins/HAL and hosted by the system's audio server rather than by client apps. A HAL driver publishes audio devices: their sample rates, channel layouts, and streams. Because the driver lives in the audio server, the DAL-style injection problem never applied; apps were always insulated from the driver's code.

This is the mechanism behind a long lineage of virtual audio devices on the Mac — Soundflower, the early open-source standby for routing audio between apps, and its modern successor BlackHole among them. Historically these were loopback pipes: one app plays into the virtual device, another records from it. A virtual microphone is the same plumbing with processing in the middle — a real mic's input runs through a pipeline and re-emerges as a new input device any app can record from, with the added latency of that round trip as the main engineering budget to manage.

Why the receiving app needs zero integration

The quiet elegance of both mechanisms is what's absent: cooperation. Zoom has no idea DeskBroadcast exists, and doesn't need to. When a conferencing app starts, it asks the OS for capture devices; the OS returns physical and virtual ones in the same list, described the same way. Selection, format negotiation, frame delivery — all identical, which is why a virtual device that misbehaves looks exactly like a flaky webcam to the app, and one that behaves is indistinguishable from hardware. This is the same class-driver logic that makes UVC webcams plug-and-play, applied one layer up: standardize the interface, and implementations compose without coordination. It's also what makes the on-device processing model possible. Everything — segmentation for background blur, color work, noise reduction, compression — can happen in one pipeline before the frame or buffer is published, and every downstream app receives the finished result without knowing any processing occurred.

In DeskBroadcast

DeskBroadcast publishes two virtual devices. DeskBroadcast Camera is a CoreMediaIO Camera Extension — the modern, sandboxed, user-approved mechanism described above, not a legacy DAL plug-in. DeskBroadcast Mic is a Core Audio HAL driver installed in /Library/Audio/Plug-Ins/HAL. Any app that can pick a camera or microphone — Zoom, Meet, Teams, Slack, FaceTime, OBS, a browser tab — simply selects them from its device menu and receives the fully processed feed. The mic pipeline engages on demand: it runs only while some app is actually capturing from the virtual mic, so your real microphone isn't held open around the clock. And all processing is on-device — frames and audio never leave your Mac on their way to the app that displays them.