Proxy Audio Device: a macOS HAL driver that hands your volume keys to an interface

Volume keys that do nothing on an interface without volume control

Some audio interfaces have a hardware volume knob that does not work, or works at the wrong level, or is simply absent. On macOS the system volume control, the menu bar icon and the keyboard volume keys then have nothing to act on, because the system is talking to a device that does not implement the control.

Proxy Audio Device is a HAL virtual audio driver for macOS that sends all output to another audio device. Its stated main purpose is to make it possible to use the system volume controls, such as the volume menu bar icon or the volume keyboard keys, to change the volume of external audio interfaces that do not allow it. The documentation adds that it might be useful for something else too, which is a candid way of saying that the general mechanism, a device that proxies to a device, is the real feature.

The mechanism is a redirection rather than a mixer. macOS keeps sending its audio to the normal output, the proxy device receives it, and the proxy passes it to whichever output device the user selected. From the system's point of view the volume keys now have a device to talk to, and the change is applied downstream.

The audience is a single-macOS user with a specific hardware problem. This is a driver, not a library, and it is written in C++ with an Xcode project.

The settings app decides the name, the target and the buffer

A virtual driver needs a configuration, and the project ships one as a separate application, the Proxy Audio Device Settings app. The documentation describes its three settings plainly: the proxy output device's name, which output device the driver will proxy to, and how large you want its audio buffer to be.

Each of those three is a real decision rather than a preference. The name is what appears in Sound preferences and in the output device list, so it is the label you will use to route applications to the proxy. The target is the physical device the audio ends up in, and choosing it once in the settings app means every application that outputs to the proxy inherits that choice, which is the whole point of the trick.

The buffer is the one with consequences. The driver holds audio between receiving it and forwarding it, and the size of that buffer trades latency against robustness. The documentation warns that if the audio buffer is too small, the driver will introduce pops, crackles, or distortion, and suggests increasing the buffer size. It is listed as an issue rather than as a configuration warning, which is fair, because the symptom appears in the audio rather than in a dialog.

The repository layout matches this two piece design: a `proxyAudioDevice/` directory for the driver itself, a `ProxyAudioDeviceSettings/` directory for the settings app, a `shared/` directory for code both use, an entitlements file for the settings app, and the `proxyAudioDevice.xcodeproj/` Xcode project that holds them together.

Installing with Homebrew or MacPorts

Two package managers are documented, and both are one line. Homebrew installs it as a cask:

brew install --cask proxy-audio-device

MacPorts installs the port:

sudo port install proxy-audio-device

The project also links a repology packaging status badge, which is where you can see which distributions and repositories carry a package. After installation, the documentation says to run the Proxy Audio Device Settings app to configure the new audio device, which is the same configuration step as in the manual path.

Manual install drops a bundle into the HAL plug-in directory

The manual path starts by downloading the latest release from the repository. The driver is a bundle that has to live where Core Audio looks for third-party drivers, so the first step creates that directory if it does not exist:

sudo mkdir /Library/Audio/Plug-Ins/HAL

Then the bundle is moved into it and given the right owner, run from the root directory of the unzipped file:

sudo mv ./ProxyAudioDevice.driver /Library/Audio/Plug-Ins/HAL/
sudo chown -R root:wheel /Library/Audio/Plug-Ins/HAL/ProxyAudioDevice.driver

Core Audio has to be told to pick up the new driver. The documentation gives the command for the system version in use:

# macOS <= 13
sudo launchctl kickstart -k system/com.apple.audio.coreaudiod

# macOS >= 14.4
sudo killall coreaudiod

The comment lines are part of the documented snippet, and they mark the fact that the mechanism changed between macOS versions. The final step is to run the settings app and set the device name, the output to proxy to, and the buffer size.

One inconsistency is worth flagging before you follow the text. The prose refers to moving the directory `ProxyAudioDriver.driver`, while the command that follows moves `./ProxyAudioDevice.driver`. The commands are the authoritative part, and the name in the prose appears to be a typo, but if you follow the prose you will look for a directory that is not in the archive.

Uninstalling means deleting the bundle and restarting Core Audio

Removal is the mirror image of installation, and the documentation treats it as a first class procedure rather than an afterthought. The bundle is removed with:

sudo rm -rf /Library/Audio/Plug-Ins/HAL/ProxyAudioDevice.driver

and Core Audio is restarted with the same version dependent command used during setup, either `sudo launchctl kickstart -k system/com.apple.audio.coreaudiod` on macOS 13 and earlier or `sudo killall coreaudiod` on macOS 14.4 and later.

That the procedure is this short is a point in the driver's favour. A virtual audio device is loaded by the operating system at the system level, which is exactly the kind of thing that leaves residue when it is removed badly, and here the footprint is a single bundle in a single directory. The cost of that simplicity is that installation and removal both need administrator rights, and both need a Core Audio restart, which briefly interrupts audio for the whole system.

The building instructions are equally short: clone the repository, open the Xcode project, build the driver and the settings application, then follow the installation instructions above. There is no documented command line build, so producing a custom build means using Xcode.

One target device, two channels, and a buffer you can ruin

The list of possible future work in the documentation is an honest statement of the current limits. It lists an indicator in the settings app for when the proxy audio device overruns its buffer and causes audio artifacts, proxying more than two channels of audio, and the ability to increase the number of proxy devices.

Read that as a boundary statement. Today the driver proxies to one device, the channel count is limited to two, and there is one proxy device per install. If your setup needs a multi-channel interface with more than two channels of content, or you want a separate proxy for headphones and another for speakers, the driver does not do it yet. The buffer overrun indicator also means the failure mode is currently invisible: the settings app cannot yet tell you that the buffer was too small, so you diagnose it by ear and by raising the size until the artifacts stop.

That is the main operational risk of the tool, and it interacts with the installation method. A large buffer costs latency, so a user who hits crackles raises the size and gets a longer delay between their keypress and the sound. The trade is real and unavoidable, and the documentation only points at one side of it.

Unlicense terms, a beta tag, and an uneven release history

The licence is the Unlicense, which is the dedication of the code to the public domain, and the `LICENSE` file sits at the repository root. There are no conditions attached to reuse, which is a rare and simple position for a driver that people do run with administrator rights on their machines.

The release history is uneven, and that matters more than the licence here. The newest tag is v1.1.0b1, a beta 1 build dated 2026-08-29, and the last push to the repository carries the same date. Before that came v1.0.7, described as Sonoma compatible and dated 2023-11-20, and v1.0.6, described as Apple Silicon compatible and dated 2022-08-30. The two older tags are named after the macOS versions and chip architectures they addressed, which tells you the two things that have actually broken this driver in practice: a new macOS release and a new Mac.

So the upgrade question is concrete. Between the 2023 stable build and the 2026 beta there is a gap in which macOS versions have come and gone, and the artifact that is current on the repository is a beta rather than a stable release. A cautious installation is to try the beta on a machine where audio failure would not cost you a session, and to keep the removal command from the documentation handy before you start, since the manual path writes into a system directory.

Editorial conclusion

Proxy Audio Device fits a macOS user with an external interface whose hardware volume control is missing, fixed, or inconvenient, and who wants the system volume keys and menu bar icon to work against it. It does not fit a setup that needs per-application routing, more than one proxy device, or more than two channels, since none of those are in the driver today, and it is a poor fit for anyone unwilling to install a system-wide audio plugin and restart Core Audio. Before you install it, run the driver once with a generous buffer, because a buffer that is too small produces pops and crackles, and check the release you download, since the newest tag is a beta rather than a stable build.

Frequently asked questions

Official sources

1. briankendall/proxy-audio-device on GitHub
2. Issues
3. License: Unlicense
4. README
5. Releases