The issue that made me read FineTune’s source properly was #402, titled “Nothing, I just want to say thank you.” It sits in a tracker otherwise full of Bluetooth bugs and feature requests. People don’t usually open issues to thank a volume slider, so I wanted to know what it was doing that macOS doesn’t.
Windows has had a per-app volume mixer since Vista. On a Mac you get one system slider plus whatever control each app bothers to expose, which for a browser tab is usually nothing. One knob for everything.
What FineTune is
FineTune is a macOS menu bar app by Ronit Singh that gives every app currently making sound its own volume slider. It ships as a DMG and a Homebrew cask under GPL v3, written in Swift and SwiftUI.
Beyond the sliders, it adds 2x to 4x gain boost per app, routing individual apps to different outputs or to several at once, a 10-band EQ per app, and AutoEQ headphone correction. The repo pitches it as a free alternative to Rogue Amoeba’s SoundSource. At 9.8k stars and 660 commits, plenty of people have taken it up on that.
Why bother
The honest objection is that this is already solved. SoundSource exists, it’s polished, and Rogue Amoeba has been shipping Mac audio tools for more than twenty years. Paying for a mature tool is usually the right call.
My answer is partly price and mostly curiosity. FineTune’s source shows how much of this Apple now lets an ordinary app do without installing anything into the audio system, and that changes what “per-app volume” costs to build. I didn’t expect the codebase to be the most interesting part.
The part I actually find interesting
I assumed, going in, that FineTune would install a virtual audio driver, the way BlackHole and older routing tools do: a HAL plug-in in /Library/Audio/Plug-Ins/HAL that every app’s sound is pushed through. I was wrong. There’s no driver anywhere in the repo. FineTune is built on Core Audio process taps, the API Apple added in macOS 14.2, and the whole design hangs on one property.
// FineTune/Audio/Engine/ProcessTapController.swift (trimmed)
let streamTap = CATapDescription(processes: app.processObjectIDs,
deviceUID: deviceUID,
stream: outputStream)
streamTap.uuid = UUID()
streamTap.muteBehavior = .mutedWhenTapped // the app no longer reaches the speakers directly
streamTap.isPrivate = true
var tapID: AudioObjectID = .unknown
let err = AudioHardwareCreateProcessTap(streamTap, &tapID)
// if this fails, it retries with CATapDescription(stereoMixdownOfProcesses:)
For each app, FineTune taps that app’s processes and sets .mutedWhenTapped, so the app’s normal output goes silent while the tap exists. It then builds a private aggregate device called FineTune-<app id> that contains the tap plus the output device you’ve picked. The audio is captured, run through FineTune’s own gain and EQ stages, then loudness processing, then a limiter, and played out of the aggregate. Multi-device output falls out of the same structure: the first device in the aggregate is the clock source and the rest get drift compensation. Volume changes are smoothed with a 30 ms exponential ramp, calculated from the device’s real sample rate, so slider moves don’t click.
The catch is obvious once you see it. If FineTune dies, every tapped app stays muted.
The author clearly hit this. CrashGuard.swift installs handlers for SIGABRT, SIGSEGV, SIGBUS and SIGTRAP that destroy every tracked aggregate device through a Mach IPC call to coreaudiod before re-raising the signal. The device IDs live in a fixed 64-slot C buffer rather than a Swift array, so the handler stays async-signal-safe. A kill -9 can’t be caught by anything, so OrphanedTapCleanup.swift covers that case on the next launch by scanning for aggregate devices named FineTune-* and destroying them. Those two files are the most honest code in the project.
It also explains the permission prompt. FineTune asks for Screen & System Audio Recording because, mechanically, it records every app it controls.
Driving it from a terminal
# install
brew install --cask finetune
# Spotify to 80%, Discord to 40%, in one call
open "finetune://set-volumes?app=com.spotify.client&volume=80&app=com.hnc.Discord&volume=40"
# route one app to a specific output (device UID is copyable from the device inspector)
open "finetune://set-device?app=com.spotify.client&device=YOUR_DEVICE_UID"
# put every app back to 100% and unmuted
open "finetune://reset"
The URL scheme accepts volumes up to 400, which is the 4x boost. Boosting that far would clip, so a soft-knee limiter is the last stage before output: samples below 0.95 pass untouched and anything above is compressed asymptotically towards 1.0. The loudness compensation feature uses ISO 226:2023 equal-loudness contours to add bass and treble back at low volumes. AutoEQ profiles are pulled straight from the jaakkopasanen/AutoEq repo on GitHub, or you can import an EqualizerAPO-style ParametricEQ.txt. The global hotkeys are a nice touch: “App Volume Down” targets whichever app is actually audible, not the frontmost one, so a YouTube tab behind your terminal is what gets quieter.
Device volume picks a backend per output (hardware, DDC for external monitors, or software inside FineTune’s own graph) and lets you force software when a USB DAC advertises a hardware slider that does nothing.
Caveats, honestly
Bluetooth can add serious latency. Issue #424 reports roughly half a second of A/V desync on Bluetooth output in v1.9.0, gone when FineTune quits. A second user confirmed it on macOS 26.5.2, and there’s no maintainer reply yet.
It can silence other users on the same Mac. Issue #418 describes no sound in any other logged-in session while FineTune runs in one. If your Mac has more than one account in use, this matters.
Calls and audio tools don’t like being tapped. The project’s own troubleshooting guide says tapping FaceTime, WhatsApp and similar apps can break echo cancellation, and lists Rogue Amoeba’s tools and DAWs as likely trouble. The fix is to ignore those apps, which removes the tap entirely.
The permission is broad. Screen & System Audio Recording is the same grant screen recorders get, and the app also holds the network-client entitlement for AutoEQ downloads and Sparkle updates. The only HTTP code in the repo is the AutoEQ fetcher and nothing I read sends audio anywhere, but you’re trusting one developer’s signed build with every sound your Mac makes.
“macOS 15 or later” is slightly optimistic. The README says 15.0, but the Xcode project’s deployment target is 15.4, so I’d expect the release build to refuse anything older. Both the EQ and AutoEQ are also stereo-only: on a multichannel tap they’re skipped, and the only sign is a line in the log.
One maintainer, and it’s gone quiet. The last commit on main and the v1.9.0 release both landed on 9 July 2026. The tracker has well over 150 open issues and 48 open pull requests.
If you take calls on Bluetooth headphones all day or share a Mac between accounts, I’d skip it for now. Same if Loopback and a DAW are already part of your setup.
Where it sits next to SoundSource
| FineTune | SoundSource | |
|---|---|---|
| Best at | Free and readable, per-app EQ, AutoEQ built in, URL-scheme automation | Years of edge-case handling and commercial support |
| Falls down on | Bluetooth latency, multi-user Macs, apps with their own audio engines | Paid licence, closed source |
What I’d steal
The cleanup pattern. If your app creates state inside a shared system daemon, assume you’ll be killed without warning, give everything you create a recognisable prefix, and sweep up your own debris on the next launch. FineTune does it in under 50 lines, and it’s the difference between a crash and a Mac that mysteriously stops playing Spotify.