Skip to content

Installation

Jump to bottom
Score2 edited this page Aug 15, 2026 · 2 revisions

Installation

AudioHub 1.0.0 ships as a macOS disk image and a Windows installer, both built by GitHub Actions and published on the releases page.

Neither build is signed for distribution. macOS and Windows will both refuse to run them until you explicitly override that refusal. That is expected, it is not a bug in the download, and getting past it is a security decision only you can make. Read Is this safe to override? before you do it.

Installation is not one step. On macOS it is three, and two of them happen inside the app after it is installed. On Windows it is one step plus a separate driver action you may never need.

What you download

Platform File Contains
macOS AudioHub-1.0.0-dev.dmg Install AudioHub.pkg, Uninstall AudioHub.app, Read Me.txt
Windows AudioHub_1.0.0_x64-setup-dev.exe The app, the service, the CLI, and the driver files (not installed)

The -dev suffix is deliberate. The build scripts rename any artifact that was not signed with real certificates so an unsigned build can never quietly take the place of a signed one. The release itself is a normal release, not a pre-release: 1.0.0 is finished, it is simply unsigned, and those are different statements.

Keep the macOS .dmg. The uninstaller is on the disk image and is never copied to your disk — see Uninstalling.

Is this safe to override?

Code signing answers one question: did this file come from the party it claims to come from, unmodified? An unsigned build cannot answer it. Neither Gatekeeper nor SmartScreen is claiming AudioHub is malicious; both are saying they have no way to check.

What this means in practice:

  • Only override for a file you fetched yourself from the project's own releases page. The release notes list the SHA-256 of every asset; if you can, compare it (shasum -a 256 <file> on macOS, Get-FileHash <file> on Windows) before you install.
  • On Windows there is a second layer: the installer carries an unsigned AudioHubVad driver. Windows will not load an unsigned kernel driver on a normal machine, and AudioHub does not try to make it — see The driver on Windows.
  • Overriding the OS check is your decision and your risk. Nothing on this page is a claim that these builds are safe; it is a description of what the operating system does and why.

macOS

Requires macOS 11 or later. The app is Apple Silicon.

Step 1 — Install the app

  1. Open the .dmg. The volume is named AudioHub 1.0.0.
  2. Double-click Install AudioHub.pkg.
  3. macOS blocks it, because the package is unsigned and the app inside carries only an ad-hoc signature with no notarisation. The wording of the block differs between macOS versions.
  4. Open System Settings › Privacy & Security, scroll to the security section, and use the Open Anyway button that now names the blocked package. Then run the package again.
  5. macOS may ask for an administrator password to write to /Applications.

This package installs exactly one thing: /Applications/AudioHub.app. It runs no install scripts, it starts nothing, and it cannot be redirected to another folder. It does not install the background service and it does not install the audio driver — both are separate, explicit actions you take later.

Do not move the app. The next step refuses to run unless the app is at /Applications/AudioHub.app, and says so.

Step 2 — Install the background service

Open AudioHub. The window shows a single card, Set up the AudioHub service, with one Install button. There is nothing else to click: AudioHub is two processes, and the UI is a client of a service that does not exist yet.

Pressing Install raises the standard macOS administrator authorization sheet, attributed to AudioHub itself. Approving it:

  • copies the service out of the app bundle into /Library/Application Support/AudioHub/service/versions/<hash>/,
  • re-signs that copy with a certificate generated on your machine, named AudioHub Local Code Signing,
  • starts the service, and
  • turns Start at login on, because this is a first setup.

After this, nothing runs as root. The service runs as you — it has to, because macOS attaches microphone, screen-recording and local-network permission to the logged-in session, and a root process would not have them.

The local re-signing is the reason this step exists at all rather than the app just launching the copy inside its own bundle. macOS records permission grants against a program's code identity. A bundled copy changes identity every time the app is rebuilt, which silently revokes every permission you granted. A certificate generated once on your machine gives the service one identity that survives app updates. A release build of the app will not run the bundled copy at all — it will only ever run the installed, locally signed one.

If you cancel the authorization, nothing changes and the same card is waiting when you reopen the app.

Step 3 — The permission gate

Once the service is connected, AudioHub shows its first-run permission screen. It is covered on its own page: First Run.

Step 4 — Install the driver (only for Mode B)

Skip this unless you want Mode B · Virtual, which puts paired machines into the system's own audio device list. Share and Mode A · Driverless need no driver.

Go to Settings › Mode. When no driver is present the Mode B option is greyed out and an Install Driver button sits below the picker. It asks to confirm — Install AudioHub Driver? — and warns that system authorization is required and that system audio will pause briefly while the driver loads. That pause is real: installing the driver restarts Core Audio.

The driver lands at /Library/Audio/Plug-Ins/HAL/AudioHubDriver.driver. It is a user-space Core Audio plug-in, not a kernel extension.

Windows

Requires 64-bit Windows. The installer is per-machine.

Running the installer

  1. Run AudioHub_1.0.0_x64-setup-dev.exe.
  2. SmartScreen blocks it — Windows protected your PC — because the installer is unsigned. Choose More info, then Run anyway.
  3. Accept the UAC prompt. This is a per-machine install; it writes to C:\Program Files\AudioHub and it cannot be pointed anywhere else. A custom directory, a redirected one, or one belonging to another product is rejected before a single file is touched.
  4. The installer is available in English and Simplified Chinese.

Unlike macOS, there is no second setup step. Before it finishes, the installer drops back to your normal user account, registers the background service, and starts it. If that fails, the installer stops and reports it rather than claiming a partial setup succeeded.

The service runs as you, not as SYSTEM, for the same reason as on macOS: a service in session 0 cannot reach your audio endpoints.

Start at login is on after a fresh install

A fresh install registers a scheduled task named AudioHubDaemon and leaves it enabled. You can turn it off afterwards under Settings › General › Start at login.

An upgrade does not re-enable it. If the previous install recorded that setup had completed and the task is missing, that combination is read as your deliberate opt-out and is preserved.

The firewall rule covers Domain and Private only

The installer adds one inbound rule, named AudioHub daemon (Domain, Private), allowing inbound connections to audiohubd.exe on the Domain and Private profiles.

A network classified as Public is not covered. Everything outbound still works — you can scan, you can dial a peer by IP, you can pair — but peers cannot open a connection to this machine, so anything that depends on the other side calling in will silently not arrive. Windows classifies unknown networks as Public by default.

If peers cannot reach this machine, check the network profile first: Settings › Network & Internet, open the active network, and set it to Private.

The driver on Windows

The installer copies the driver files to C:\Program Files\AudioHub\windows-driver\ and does not install them. It also never imports a certificate and never enables test signing.

Install Driver exists in Settings › Mode and will ask for elevation, but on an ordinary Windows machine it will fail, and that is intentional. The AudioHubVad driver in these builds is unsigned, and AudioHub asks Windows to install it non-interactively — which makes an untrusted package fail closed rather than prompt you past a trust decision. Mode B is therefore not reachable on Windows with a build from CI.

Share mode and Mode A are unaffected and need nothing from this section.

If the window is blank

Development builds of the Windows installer deliberately skip installing the WebView2 runtime, so that repeated test installs never depend on a network download. Windows 11 ships WebView2; a Windows 10 machine without it will start AudioHub with a window that does not render. Install the Microsoft Edge WebView2 Runtime from Microsoft and reopen AudioHub.

What the installers deliberately do not do

Both platforms hold the same line: installing the application must never create an audio device behind your back.

macOS Windows
Installs the app Yes Yes
Installs the background service No — explicit action in the app Yes, during install
Installs the audio driver No — explicit action in Settings › Mode No — files staged only
Turns Start at login on Yes, when the service is first installed Yes, on a fresh install
Adds a firewall rule No Yes, Domain + Private, inbound
Runs anything as root / SYSTEM No No

Where things end up

What macOS Windows
Application /Applications/AudioHub.app C:\Program Files\AudioHub
Background service /Library/Application Support/AudioHub/service/versions/<hash>/ beside the app, no separate copy
Audio driver /Library/Audio/Plug-Ins/HAL/AudioHubDriver.driver staged in windows-driver\, not installed
Start at login LaunchAgent com.audiohub.app.autostart scheduled task AudioHubDaemon
Your settings, identity, pairings, logs ~/Library/Application Support/AudioHub %APPDATA%\AudioHub

The last row is user data and no uninstaller touches it. See Uninstalling for what that means.

Upgrading

Install the new build over the old one.

On Windows that is the whole procedure. The installer stops the running service first and refuses to proceed if it cannot — no program files are replaced underneath a live service.

On macOS the package replaces /Applications/AudioHub.app and nothing else. The next time you open AudioHub the Set up the AudioHub service card is back, because the service matching this build is not installed yet. Approve it again; the previous service is stopped and replaced.

Your settings, identity, pairings and driver survive an upgrade on both platforms, and so does a Start at login you previously turned off — a recorded setup plus a missing login entry is read as your opt-out, not as something to repair.

One macOS wrinkle worth knowing: each installed service version lives in its own hash-named directory and old versions are never deleted. They are inert — only the current one is ever started — but they accumulate across upgrades. The uninstaller is what clears them.

Next

AudioHub

Start here

Using AudioHub

How it behaves

Reference

Troubleshooting and removal

This wiki describes AudioHub 1.0.0.

Clone this wiki locally