-
Notifications
You must be signed in to change notification settings - Fork 0
Platform Notes
AudioHub targets macOS and Windows 10 or later. Nothing below Windows 10 version 2004 is considered.
macOS grants these per application, and its rule is unforgiving: once a permission is denied, the application can never prompt again — it must be enabled by hand in System Settings. AudioHub therefore asks for everything it needs up front, and the settings page shows live probe results rather than remembered ones.
| Permission | Needed for | Required? |
|---|---|---|
| Microphone | Sharing this Mac's microphone with paired hosts | When sharing |
| Local Network | Discovering other AudioHub hosts and exchanging audio | Yes |
| System Audio Recording | Mode A's "send this machine's audio to the peer's speaker" | Only for system audio capture |
Audio never leaves the local network. There is no cloud component.
If Local Network is not granted, this machine will not be discoverable — but pairing by typed IP, accepting inbound connections, and scanning for others all continue to work.
macOS has exactly one capture backend: the Core Audio process tap, requiring macOS 14.2 or later.
ScreenCaptureKit is a technically viable alternative and has been declined permanently. The reasoning is worth stating plainly, because it is a cost we chose to pay:
- SCK's audio capture requires the Screen Recording permission. Asking a user for screen access to run an audio tool is a materially larger request, and macOS re-prompts for it periodically.
- The only versions SCK covers that the process tap does not are macOS 13.0 through 14.1 — a 14-month band. Below 13, SCK has no audio capture either.
- So on any machine where SCK would work, the process tap works too, or neither does.
This is a cost, not a red-line issue. SCK is equally a side tap and would equally have left your output device alone. Declining it costs users on 13.0–14.1 the mode A speaker direction, and on those machines there is no fallback.
The UI distinguishes "not available on this machine" (your OS is too old — upgrading fixes it) from "not provided by this project" (nobody can fix it) as two different sentences, because they lead to different actions.
Status: the capture implementation is complete but the path has not yet executed end to end, pending a TCC grant on the development machine. Prompt behaviour, device-switch handling, CPU cost and long-run stability are unmeasured.
macOS uses a Core Audio Server Plugin — user space, ordinary code signing is
sufficient, no kernel extension and no reduced security mode. It installs to
/Library/Audio/Plug-Ins/HAL/ and talks to the service over a shared-memory ring.
Devices are identified by UID, and the display name is decorative. Renaming a peer therefore happens in place under the same UID, so applications never see a device change and never lose a remembered selection.
Apple Spatial Audio is not available to third-party HAL devices, and macOS has no equivalent of Dolby Access. The only genuine Atmos route on macOS is passthrough to hardware on the peer's end.
Windows does not grant audio permissions per application the way macOS does. The permission rows in settings generally report "no authorisation needed on this platform"; the settings page carries platform-appropriate wording rather than repeating the macOS rule.
Two backends, selected at runtime:
| Backend | Requires | Excludes AudioHub's own playback |
|---|---|---|
| Process-exclusion loopback (preferred) | Windows 10 2004+ | yes |
| Device loopback (fallback) | Vista+ | no |
The preferred backend naturally excludes AudioHub's own output, which directly prevents the feedback loop you would otherwise get when both machines send to each other. The fallback captures everything including AudioHub's own playback, so it warns about possible feedback when both directions are active.
Acoustic echo cancellation — speaker bleeding into microphone — is out of scope.
Status: developed and tested, but not signed for release. End users cannot install it.
Windows offers no user-mode audio driver framework, so a virtual audio device requires a kernel-mode driver (PortCls/KMDF). That is a platform fact, not a choice.
What works today, on a test-signing machine:
- The driver loads, and the device pair appears in the system audio device list.
- Audio passes from one machine to another through it, measured at +57.6 dB SNR.
- Volume topology is correct: peer-side volume and source amplitude compose exactly once, with no double attenuation. Calibration against real hardware matched the expected decibel table to within 0.000 dB across 20 points in each direction.
- Driver Verifier passes. An earlier soak produced repeatable bugchecks; three distinct IRQL defects were found and fixed, and a ten-minute soak under the same standard flag set now completes with no bugcheck.
What does not:
- It is not formally signed. Shipping it would require an EV certificate and attestation signing, which is out of scope. With Secure Boot on and test signing off — i.e. an ordinary machine — the driver is refused.
- Renaming a peer cannot be done in place on Windows. Endpoint names are cached by the property store, and the only mechanism that forces a refresh marks the endpoint absent and steals the user's default selection — which is precisely what in-place renaming exists to avoid. This is an accepted limitation, not a pending fix.
- Cross-machine evidence exists for the render direction only; the microphone direction is unverified.
Therefore, for Windows end users: mode A plus a third-party signed virtual sound card (VB-Cable and similar) is the supported path. Mode B is greyed out.
If a Windows audio driver does not declare volume support, the audio engine silently inserts its own software volume stage in front of the driver. The driver then never sees full-scale samples, the peer attenuates again on its side, and you get double attenuation that is invisible from the application's point of view.
So "not implementing volume" on Windows does not mean "no volume control" — it means volume gets applied somewhere you cannot see. AudioHub's driver declares a volume node for exactly this reason. macOS does not have this problem, because the HAL plugin sits before the volume stage.
Windows appends a parenthesised suffix that is shared across all peers and cannot carry per-peer content, so a device ends up displayed as:
AudioHub – <hostname> Speaker (AudioHub Virtual Audio)
Everything before the parenthesis is identical to the macOS side, character for character.
| macOS | Windows | |
|---|---|---|
| Share mode | Yes | Yes |
| Mode A (driverless) | Yes, 14.2+ for system audio | Yes, 10 2004+ preferred backend |
| Mode B (virtual devices) | Yes — user-space plugin | Unsigned — kernel driver works on a test-signing machine; end users cannot install it |
| Third-party bridge card | BlackHole | VB-Cable |
| Per-peer device rename in place | Yes | No — platform limitation |
Using it
How it behaves
Settings
Reference