-
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 (BlackHole on macOS, VB-Cable on Windows). AudioHub writes the peer's microphone into that card's playback side; any application selecting that card's input side is then hearing the peer's microphone.
AudioHub does not install these drivers and does not bundle them. If one is detected, the option becomes selectable; if not, it is greyed out with a link to the vendor.
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