-
Notifications
You must be signed in to change notification settings - Fork 0
Home
AudioHub shares audio devices across machines on a local network. Pair two computers, and each can use the other's default microphone and default speaker as if they were its own.
It is not a conferencing app and not a music streamer. It moves raw audio between two machines you own, with the latency and quality knobs exposed rather than hidden.
You have two machines on one desk. The good microphone is plugged into one of them; the good speakers are plugged into the other. The meeting is on the third. Moving cables is the usual answer, and it is a bad one.
AudioHub makes the other machine's default input and output selectable from this machine — either inside AudioHub itself, or, with the optional driver, from the system's own audio device list, so any application can pick it.
Two deliberate non-goals shape everything else:
- No device enumeration. AudioHub shares "the other machine's default microphone / default output". It does not present you with a list of the peer's sound cards. Whatever that machine is set to use, you get.
- No cloud, no relay, no NAT traversal. Audio goes directly between the two machines. If they cannot reach each other, AudioHub does not route around it.
| Page | What it covers |
|---|---|
| Operating Modes | Share mode, consumer mode A (driverless), consumer mode B (virtual device), why exactly one may be active, and bridging to a third-party virtual cable |
| Discovery and Pairing | Ports, what the local-network broadcast contains, fingerprints, the PIN exchange, and what unpairing removes |
| Transport Tiers | Tier 0 (UDP) / Tier 1 (TCP media) / Tier 2 (single-connection multiplex), when each is used, what it costs, and the tunnel address |
| Audio Quality | The six-rung quality ladder and how AUTO moves along it |
| Latency | Measured end-to-end latency, where the milliseconds actually go, and how we measure them |
| Volume | Why loudness and slider numbers cannot both match across two machines |
| Platform Notes | macOS permissions, system audio capture, Windows driver status |
| Settings Reference | Startup at login, keyboard shortcuts, virtual device options, config paths |
| Web Access | Driving AudioHub from a browser, and why "local only" is locked |
| Glossary | Jitter buffer, underrun, PLC, tier, taper, and friends |
AudioHub runs as two processes: a background audio service that owns the devices and the network, and a UI that is a thin client over a local IPC channel. The CLI speaks the same IPC contract. Closing the window does not stop the audio.
Discovery is automatic on the local network (mDNS), with manual IP[:port] entry
as an always-available alternative that also works across subnets. Pairing is a
one-time exchange of a 6-digit PIN; once it succeeds, trust is bidirectional
and each machine appears in the other's list.
The default port is 47810, with TCP and UDP sharing the same port number.
AudioHub will never ask you to switch your system output to a virtual device.
The common workaround for capturing system audio — install a loopback driver, point your system output at it, and now you can no longer hear anything without a second monitoring path — is the exact experience this project treats as unacceptable. System audio capture is a side tap. Your output device and its volume stay exactly as you left them.
Several pages here quote measured figures — latency breakdowns, decibel discrepancies, buffer depths. Two ground rules apply to all of them:
- A measurement is dated and scoped. Numbers come from a specific pair of machines on a specific date with a specific configuration. They are stated as what was observed, not as a specification we promise to meet.
- A missing measurement is never filled with zero. Where a value cannot be read, the UI shows the number prefixed with ≥ and says which term is missing, rather than silently reporting an optimistic total. See Latency.
Using it
How it behaves
Settings
Reference