Skip to content

Virtual Driver

Score2 edited this page Aug 15, 2026 · 1 revision

Virtual Driver

Mode B publishes each paired host into this machine's own system sound settings, so any application can pick it like a real device. That requires a driver, and the driver is never installed for you. Both installers ship the payload and then stop: on macOS the package installs only AudioHub.app, and on Windows the installer copies the driver files under the install directory without registering them. Turning the driver on is always one explicit action you take inside the app.

That action is a single button, described below. Mode A and Share do not use the driver at all and are unaffected by everything on this page.


Where the button is

Settings › Mode — the first card on the settings page, the same card that holds the Share / A · Driverless / B · Virtual picker. The button sits in the row directly under the picker, next to whatever status line the driver currently warrants.

It exists only in the desktop app. The browser Web UI never shows it: installing a driver is a privileged, machine-local operation and the person clicking in a browser is usually not at that machine. See Web Access.

The button is greyed out while an install or restart is running, and also when this build reports the driver as unsupported on this platform or as not bundled.


What the button says, and when

The label is not decoration — it tells you which operation will run.

Label Shown when What it does
Install Driver No driver package is installed Installs the bundled payload
Repair Driver A package is installed but the bridge is not healthy, or the driver is fine and you want to reinstall it anyway Reinstalls the same bundled payload over the top
Update Driver The service and the installed driver disagree on protocol version Installs the bundled payload, replacing the mismatched one
Restart Service The driver package is installed and registered, but its bridge is not connected Restarts the local service only — no driver files are touched, no authorisation is asked for
Installing… / Restarting… While either operation runs

Repair Driver stays available even when everything is working. An installed driver has to remain repairable without first having to break it.

If a Windows install has asked for a restart and you have not restarted yet, the button disappears entirely and the row shows "Driver installed. Restart Windows to finish." There is nothing useful to press until the machine reboots.

The status line beside it

Situation What the line says
Service disconnected The service is disconnected, so driver availability can't be determined yet
No driver No AudioHub driver was detected, so Mode B is unavailable. Install it to enable Mode B
Version mismatch The driver and local service versions don't match (service vn / driver vm). No virtual devices will appear. Install the matching driver version
Registered, bridge not connected The driver is registered, but its bridge connection isn't ready. Published devices remain in the system but aren't processing audio. Wait a moment or restart the service
Healthy (no line — only the Repair button)

The two version numbers in the mismatch line are per platform. The macOS driver ABI and the Windows driver ABI are separate numbers that were never meant to match each other, so do not compare a Mac's reading against a PC's.


What pressing it does

Install, Repair and Update all show the same confirmation first:

System authorization is required. System audio will pause briefly while the driver loads.

Both sentences are literal. Restart Service shows no confirmation and asks for no authorisation.

After a successful install the app re-polls the service several times over the following seconds, so the virtual devices may take a moment to appear in your system sound settings. You do not need to restart the app.

macOS

Authorisation is the standard macOS admin sheet, raised by AudioHub itself so the sheet is attributed to AudioHub rather than to a generic helper. Cancelling it is not an error: you get "Driver install cancelled." and nothing was changed.

The audio interruption is unavoidable and is what the confirmation warns about. Loading or replacing an audio server plug-in requires retiring the running Core Audio plug-in host processes and restarting coreaudiod; every application playing audio at that moment is briefly cut off.

The app does not take the installer's word for it. It verifies afterwards that the old plug-in host processes are gone, that a fresh coreaudiod generation is running, and that the driver's Mach service has been republished. If the package completed but the system did not end up loading the driver, you get "Driver files were installed, but the system could not load them. Check signing policy and the diagnostic log." rather than a false success.

Windows

The button launches an elevated helper, so you get a UAC prompt. Declining it gives "Driver install cancelled." and changes nothing.

The helper refuses to do anything without elevation, verifies every file it is about to use against digests baked into the build, and reports one of: ready, reboot required, installed-but-unusable, or a plain failure. A restart request is honest — the package is installed, but nothing works until you reboot.


On Windows this will fail, and that is the design

The AudioHub Windows driver is not signed for distribution, and an ordinary Windows machine will refuse to load it. The button still exists and still elevates, because there is a real driver in the package and there are machines that can load it — but on a normal PC, with Secure Boot on and test signing off, the install is expected to fail.

It fails closed, on purpose. The install call is made in a non-interactive mode, which means Windows cannot fall back to putting an "install this untrusted driver anyway?" dialog in front of you — it just returns an error. AudioHub does not import a certificate, does not enable test signing, and does not try to talk you past the warning. Nothing in the installer or the app changes your machine's driver-signing policy.

Two things follow:

  • Mode B is not a shipping feature on Windows for end users. The Windows driver is developed and built, not signed and released. Treat the button as present for developers and for machines already configured to load unsigned drivers.
  • Use Mode A instead. For the speaker direction it needs no driver at all. For the microphone direction, bridge to a third-party audio bridge — a signed virtual cable such as VB-Cable — which AudioHub detects and writes into. See Operating Modes.

The macOS driver is not in this position. It is a user-space Core Audio plug-in, so it never needs a kernel-mode driver signature, and Secure Boot has nothing to say about it.


When Mode B is greyed out, and when it is merely red

These are different failures with different fixes, and the picker distinguishes them.

Picker state Meaning What to do
B · Virtual is disabled The service has no driver bridge at all — no driver installed, or the service is not connected yet Press Install Driver. If the service is offline, fix that first
B · Virtual is selectable, the status line turns red Version mismatch. The driver is there but speaks a different protocol than this service Press Update Driver. It stays selectable precisely so the button is reachable
B · Virtual is selectable, amber status line Registered but the bridge is detached. Devices remain listed in the system and pass no audio Wait a few seconds, then Restart Service

A version mismatch is the most confusing of the three because everything else looks fine: the service is healthy, the peers are connected, and there is simply not a single AudioHub device anywhere in the system.

If you have selected Mode B while it is unavailable, AudioHub says so and falls back to Mode A rather than running with no audio path: "Mode B is selected but unavailable, so AudioHub is temporarily running in Mode A."


Removing it

There is no uninstall button for the driver inside the app. Removal happens with the product:

  • macOSUninstall AudioHub.app, shipped alongside Install AudioHub.pkg in the disk image. It needs administrator authorisation and interrupts system audio the same way installing did.
  • Windows — the normal uninstaller asks whether to remove the driver too. Answering No cancels the entire uninstall, deliberately: the driver must never be left behind without the service it depends on.

See Uninstalling for the full sequence and the outcomes that are neither success nor failure.


Related

Clone this wiki locally