-
Notifications
You must be signed in to change notification settings - Fork 0
Operating Modes
AudioHub is one application with three operating modes. Exactly one is active at a time, and the choice is global to the machine — not per peer.
| Mode | Others can use this machine | This machine can use others |
|---|---|---|
| Share (provider) | yes | no |
| Consumer A — driverless system capture | no | yes |
| Consumer B — virtual devices | no | yes |
Switching modes takes effect immediately and needs no confirmation. The control sits at the top of the main panel.
The machine offers its default microphone and default output to paired hosts.
- Its microphone can be drawn by several peers at once (fan-out).
- Several peers can send audio to it at once (mixed on arrival).
- It uses no peer's devices itself.
This is the baseline form of the application: pure user space, no driver, no special privileges.
No driver required. Mode A works on any supported machine out of the box.
Sending to the peer's speaker. AudioHub captures this machine's system audio and sends it to the peer's default output. The audible result is that both machines play the sound — the capture is a side tap, and this machine's output device is untouched. Per peer, the source can be switched from system audio to this machine's microphone instead.
There is an optional volume sync setting for this direction; see Volume.
Taking the peer's microphone. This is where driverless hits a wall: without a driver, nothing can inject a new entry into the system's input device list. So mode A offers two things:
- Monitoring and recording inside AudioHub itself — always available.
- Bridging to a third-party signed virtual sound card, described next.
Sending system audio needs a capture backend, and there is more than one. The picker offers Auto, which asks the service to take the best available one, and it can be pinned per peer. Which backends exist and what each costs is platform-specific — see system audio capture.
Two properties hold on every backend: the capture is a side tap, so this machine's output device and its volume are untouched, and you are never asked to switch your system output to some virtual device. That workflow is a project-wide red line, not an omission.
One backend is worth knowing about before you pick it: Windows device loopback taps after the mixer, so it also captures AudioHub's own playback. With audio flowing both ways that is a feedback path. The process-exclusion backend does not have this problem and is preferred where it is available.
The only way a driverless install can put the peer's microphone in front of other applications: write it into a virtual sound card that someone else signed and shipped.
How it works. AudioHub writes the peer's microphone into the chosen card's playback side. Any application that selects that card's input side is then listening to the peer's microphone. AudioHub is a producer on one end of a loopback cable that already exists on your machine.
| Platform | Card |
|---|---|
| macOS | BlackHole |
| Windows | VB-Cable |
AudioHub neither installs nor bundles them. They are third-party drivers with their own signatures and their own maintenance; shipping someone else's kernel-adjacent code inside this app is not a trade worth making. Install one, restart AudioHub, and it becomes selectable. If none is detected the option is greyed out with a link to the vendor — no nagging, no "install now" button.
Which card is chosen is a per-peer setting, on the peer's card, not a global one. The set of detected cards is global; the choice is not.
If a card that was selected is no longer detected — uninstalled, or the driver failed to load — the bridge is not silently skipped. The card stays in the list marked as missing, and the UI says the path will not be bridged until you pick another one or reinstall it.
With the AudioHub driver installed, each paired host appears in the system audio device list as a pair of devices — a speaker and a microphone named after that host. Any application can select them from its normal device menu; nothing needs to know AudioHub exists.
Semantics unique to mode B:
- Devices appear on pairing, not on first use.
- Adjusting the virtual device's volume adjusts the peer's real device.
- When a peer disconnects, the devices by default stay in the list, shown as offline and passing no audio. A setting can make disconnection remove them instead; either way they return under the same UID on reconnect, so applications do not lose a remembered selection.
- Unpairing always removes them unconditionally, on both machines.
Capacity is 16 peers, i.e. 32 virtual devices.
If the driver is absent or its version does not match the service, mode B is greyed out. Mode A and share mode are unaffected. See Platform Notes for what "driver available" means on each OS — on Windows, the honest answer for end users is currently not available.
This is the part that surprises people, so it is worth the space.
A machine that both shares and consumes creates two concrete failures.
Host X shares its default microphone with host Y. X is also in mode B, and X's default input happens to be "AudioHub — Z microphone".
Y now receives Z's microphone, not X's. X has become a relay without anyone choosing that, and without any screen saying so. The same applies in the speaker direction: audio Y sends to X's default output lands on Z's virtual speaker and is forwarded onward.
If Z is in turn using X, the path closes on itself. Audio circulates, and latency grows without bound until some buffer stage saturates. Nothing in the pipeline pushes back on this; it is a topological problem, not a tuning problem.
Three follow directly, and all three are user-visible:
- Mode is advertised to peers. A host in a consumer mode is listed as not usable rather than failing when you try. The reason is shown — "it is in mode A / mode B, using another host's devices" — because "that machine is in mode B" and "that machine is switched off" deserve different next steps.
- Switching mode disconnects. Leaving share mode closes the sessions of peers currently using this machine, and notifies them. AudioHub does not refuse the switch; it performs it and says what happened.
- Mode B's virtual devices exist only under mode B. Switching away removes them from the system list rather than leaving them present and silent.
We know. There are safe configurations this rule forbids — X sharing its real microphone while consuming Z's speaker involves two paths that never intersect, and is harmless.
The rule is still absolute, because which device is being shared depends on the system default device. A user changing one system setting can turn a safe configuration into a relay, and AudioHub observes that change only passively. Detecting loops at runtime is more complex and more prone to false positives than declining to enter the situation at all.
If this proves too restrictive in practice it can be relaxed later to per-direction adjudication plus runtime loop detection. It should not be the first version's behaviour.
Using it
How it behaves
Settings
Reference