What It Actually Takes to Ship a Virtual Microphone on Windows

The Ask

A friend came to me with a deal: build a real-time voice changer for a livestreaming team. Speak into a real mic, the voice comes out transformed, and OBS/Discord/Zoom see it as just another microphone input.

My first reaction: sure, that's a solved problem, Clownfish has existed forever. Then I spent an evening researching how the existing apps actually work, and discovered the voice-changing is the easy half. The hard half is the two words everyone glosses over: virtual microphone.

---

The Easy Half: Changing the Voice

For an MVP you don't need AI at all. Classic DSP does the job:

• Pitch shifting + formant shifting on CPU with low latency. The formant part is what separates a usable product from the "chipmunk effect" — shift pitch without preserving formants and everyone sounds like they inhaled helium.
• Solid open-source options exist: SoundTouch (LGPL) for time-tested pitch shifting, or stftPitchShift (MIT) which handles formant preservation properly.
• This gets you male↔female, robot, deep-voice, alien — the preset-grid experience streamers expect. What it does not do is turn you into one specific other person; that's AI voice conversion (RVC-style), a GPU-hungry stretch goal I filed under "later."

Latency budget is the design constraint: anything over ~50ms round-trip and the streamer hears themselves on a delay, which is somewhere between annoying and unusable.

---

The Hard Half: Being a Microphone

Here's the part no tutorial tells you upfront. For your app's output to appear in OBS's device list as a microphone, something has to exist at the kernel driver level. Windows does not let userland apps declare "I am a microphone now."

How the incumbents do it:

• Voicemod, NVIDIA Broadcast, MorphVOX, Voice.ai — they all ship their own signed virtual audio driver. That's a chunk of their moat.
• Clownfish — hooks into existing audio sessions instead, with a fallback mode that asks you to install VB-Cable yourself.

So your options as a small developer are basically three, and each has a catch.

Option 1: Piggyback on VB-Cable

The famous donationware virtual cable. It works great — but redistributing it commercially means dealing with their licensing terms: donations expected from companies (in the hundreds-to-thousands range), VB branding requirements, and restrictions on bundling the A+B/C+D variants. Fine for "please install this yourself," legally murky for "our installer ships it."

Option 2: Open-source driver

The cleanest candidate is VirtualDrivers/Virtual-Audio-Driver — MIT-licensed, built on Microsoft's own SYSVAD sample. The catch: it's beta, and you must sign it yourself. Which leads to…

Option 3: Your own signed driver — welcome to the toll booth

Windows 10/11 64-bit enforces Driver Signature Enforcement. An unsigned kernel driver simply will not load — Error 52, no exceptions. The bypasses (test-signing mode with a permanent desktop watermark, or disabling DSE every single boot) are fine for your dev machine and shippable to exactly nobody.

To sign a driver for real in 2026 you need:

• An EV code-signing certificate: roughly $280–560/year, delivered on a hardware token.
• A Microsoft Hardware Dev Center account — increasingly geared toward registered companies with D-U-N-S numbers (there's a sole-proprietor path via some CAs, but it's the exception).
• Attestation signing after that — installable, though it won't ride Windows Update.

There is no free shortcut. Every "how do I ship a virtual audio device" thread eventually dead-ends at this exact toll booth.

---

The Design That Resolves It

The architecture I landed on treats the output as a pluggable sink, so the certificate question stops blocking development:

[Real mic] → [DSP engine: pitch + formant] → [Sink interface]
                                               ├─ Sink A: existing virtual device (VB-Cable, dev-signed driver)
                                               └─ Sink B: our own EV-signed driver (when the deal justifies $300+/yr)

• Demo now with Sink A: users install VB-Cable themselves (allowed), our app just outputs into it.
• Ship later with Sink B: fork the MIT driver, attestation-sign it, bundle it in the installer — if the project graduates from demo to product.

The app code is identical either way; only the last audio hop changes. The unglamorous lesson: on Windows, the boundary between "cool audio hack" and "installable product" is not your DSP quality — it's a $400 USB token and a corporate registration.

The voice-changing part? Still the easy half.