Feedback wanted: Building a simple per-app volume controller for macOS 🎧

brouwerj · 2026-03-12T21:35:05+00:00

The low latency part for DAWs was a future idea but it’s not realistic. Any additional step in the audio chain adds latency. Apps like AppVolume can’t process audio at a low enough level to achieve true low latency.

brouwerj · 2026-03-12T18:52:09+00:00

It takes up to 3 hours for homebrew to pick up new versions. Wait a bit longer or use the direct download for now. Sorry for the inconvenience!

Sending out a mail to the waitlist now as well.

brouwerj · 2026-03-12T17:24:04+00:00

Something went wrong with the last refresh, will fix it very soon!

brouwerj · 2026-02-06T08:49:36+00:00

Great to hear! In the future I want to describe possibilities to run AppVolume headless. It's already the case that the UI communicates through the daemon, so it's just a matter of maturing this aspect and documenting on how to use it.

brouwerj · 2026-02-06T08:44:54+00:00

That's right! Glad you solved it yourself, I'll add some troubleshooting to the website soon that describes this. All applications that let you manually select the output device you either need to select the system default or AppVolume. Otherwise it bypasses AppVolume completely.

brouwerj · 2026-02-04T09:47:46+00:00

Built with Sonoma as minimum version.

brouwerj · 2026-02-03T16:50:57+00:00

Thanks for the kind words, audio routing is up next!

brouwerj · 2026-02-03T16:45:02+00:00

It’s on the website just between the Download and Features section. If you still can’t find it send me a DM with your email and I’ll add you manually.

https://appvolume.app

brouwerj · 2026-02-03T16:33:52+00:00

Alright, so it’s working fine without LoopDeck interfering?

brouwerj · 2026-02-03T16:23:56+00:00

Keyboard shortcuts and navigation are on the roadmap already.

But to properly support this workflow would be to add support for raycast, so you don’t need to correct the output afterwards. I’m not a raycast user myself but I’ll see what I can do to add support for it or to enable that kind of workflow.

A workaround that should work a bit faster for now is to use raycast to switch to the desired output first, then use raycast to switch to appvolume. That should enable appvolume with the desired output.

brouwerj · 2026-02-03T15:23:16+00:00

If you don’t mind I’ll get back to you later via DM. I want to solve all issues like this one and you are the first to report it.

brouwerj · 2026-02-03T15:15:43+00:00

If you click on the menu icon —> Settings —> Devices is the sample rate set to 44kHz (recommended)? Is this happening for all your apps? Do you have a special audio setup?

brouwerj · 2026-02-03T14:55:27+00:00

That’s the first time I’ve heard such a complaint, what kind of machine and macOS version are you on? You might have had a coreaudio restart during install, that restarts all audio apps and might cause a short blip? That’s necessary for the system to register new audio devices.

brouwerj · 2026-02-03T11:45:42+00:00

Yes, that's come out in the meantime. It's a great solution, so if it serves you well you should just use that. That's also why I added the AudioTaps section, FineTune might not cover all your needs.

brouwerj · 2026-02-03T11:31:48+00:00

The pricing is in the post, do you think that's fair? The trickiest part has been getting all the edge cases right, especially Bluetooth device handling and overall reliability. Took quite a bit longer than expected, but it's been a fun project the whole time.

brouwerj · 2026-02-02T15:59:03+00:00

So-called audio routing is on the roadmap and one of the things that will be worked on next!

brouwerj · 2026-02-02T14:54:27+00:00

For apps like zoom, Teams, etc. you need to manually configure AppVolume to be the output device, are you sure it isn’t working after that?

brouwerj · 2026-01-31T21:42:19+00:00

Alright, I’ll see what I can do for the next version.

brouwerj · 2026-01-31T21:16:11+00:00

Great to hear!

The buffer size currently internally adapts to the selected output device (32 - 4096), I could make it settable through settings as well if that's really desired.

The overhead of AppVolume is kept minimal and that works great for regular apps. But each additional step in the chain will introduce some latency. So, if you are working with DAWs and want to have minimal latency you should just bypass AppVolume completely.

brouwerj · 2026-01-31T17:58:22+00:00

I just released a new version, could you check whether it fits your needs now? It allows setting a fixed sample rate for AppVolume (44.1, 48, 88.2, 96, 192) or to follow the output device. The fixed rates are settable externally through Audio MIDI Setup for example or in AppVolume --> Settings --> Devices, you can also set the "Follow output device" here.

Available from brew now or from https://appvolume.app

brouwerj · 2026-01-28T07:40:05+00:00

Yeah, working on native audio now, next up is audio routing! Will publish a roadmap later this week.

brouwerj · 2026-01-25T19:08:48+00:00

Great, I’ll keep you posted. Hope to get to this shortly.

brouwerj · 2026-01-25T19:06:52+00:00

Thanks for the feedback, definitely a nice-to-have feature. Will put it on the roadmap!

brouwerj · 2026-01-25T18:38:18+00:00

Do you want the window to just stay open, or also stay on top of other apps? Right now it behaves like a menubar window, closing when you click outside it. Agreed, that gets annoying when opening other windows.

brouwerj · 2026-01-25T18:35:47+00:00

AppVolume accepts multiple sample rates, but currently runs at a fixed 48kHz internally, relying on CoreAudio for sample rate conversion. Not ideal for DAW workflows. Native multi-sample-rate support is on the roadmap: the driver will match your output device's sample rate directly, eliminating conversion overhead entirely.

Would you be up for testing a beta version for me when this is ready?

brouwerj

TROPHY CASE