feat: add a per-app sound mixer switch - #213
Open
lou1s19 wants to merge 11 commits into
Open
Conversation
Add an "App Sound" settings section and an optional menu bar item that opens a mixer styled after the system Sound panel: a system-volume slider, a per-app row for every app currently playing audio, and the current output device. Two control paths cover different apps: - Scriptable media apps (Music, Spotify, TV, iTunes) via AppleScript's `sound volume`. - Any other app that outputs audio, including browsers, via a Core Audio process tap (macOS 14.4+) that scales the app's samples through a private aggregate device. The menu bar item is opt-in and is created before the hide-menubar mark item so it survives collapsing. Adds NSAudioCaptureUsageDescription for the process-tap capture prompt.
lou1s19
requested review from
dadameng,
jacklandrin,
leonmtg and
shayanbo
as code owners
July 20, 2026 13:16
Owner
|
Sorry, I updated something recently. Can you please resolve the conflicts? |
jacklandrin
reviewed
Jul 26, 2026
|
|
||
| /// Settings page for the mixer: the menu bar switch plus a live preview of the panel that the | ||
| /// menu bar item shows. | ||
| struct SoundMixerSettingView: View { |
Owner
There was a problem hiding this comment.
I think you need a new type of switch(SwitchType.swift) instead of a setting to toggle it.
Besides, we should avoid adding new icon on menu bar. So the popover content would be better to be included in the settings. Wdyt?
Resolves the conflicts jacklandrin asked about: - project.pbxproj: both sides appended to the same Sources build phase, kept both sets of files. - Localizable.xcstrings: no key was touched by both sides, so the 17 new mixer keys were inserted into upstream's file without reformatting it. Build verified with Xcode 26.6 on macOS 26.6.
Addresses the review on jacklandrin#213. - Adds `SwitchType.soundMixer` and `SoundMixerSwitch`, so the mixer is enabled in Settings > Customize like every other switch. The bespoke `Preferences.soundMixerMenubarItem` and the "App Sound" settings page are gone. - Drops the second status item. The panel now lives in the switch list popover and expands in place, modelled on `AuthenticatorPanelView`. That also removes the ~80 lines in `StatusBarController` that only existed to keep a second item clear of the hide-menu-bar mark. - Moves the files out of `Features/Settings/` into `Features/SoundMixer/` and renames the two that were named after the settings page. - Removes the twelve now-unused strings, adds "1 app"/"%lld apps". The Core Audio process tap is unchanged.
From the review pass: - refresh() now returns early unless the mixer is on. The workspace observers fire regardless of what is enabled in Customize, and it is enumerating audio processes that triggers the audio-capture prompt. - Turning the mixer off releases every process tap, so an app cannot stay stuck at a reduced gain with no interface left to raise it. - The panel header is a Button again, matching AuthenticatorPanelView, so VoiceOver and the keyboard reach it.
Crash found while testing: EXC_BAD_ACCESS in swift_release_dealloc on the main thread, with a garbage pointer. That is heap corruption, and the tap's realtime callback is the only place in the app that manages raw memory. - teardown() freed the TapState the IOProc block dereferences on every buffer. AudioDeviceStop returns before the IO thread is guaranteed to be finished, so a late callback wrote into released memory. The state is now marked retired and kept for the life of the process (16 bytes per tap rebuild), and the callback returns immediately once retired. - releaseAllTaps() mutated muteTaps while iterating its keys. - refresh() reassigned rows every two seconds even when nothing changed, which relaid out the popover under the pointer on every tick.
While a slider is dragged, setVolume was creating and destroying a private aggregate device on every movement: crossing full volume tore the tap down, and any change to the app's process set rebuilt it. Each of those is a synchronous Core Audio setup on the main thread, which is what made the UI hang before it crashed. The live path now only writes the tap's target gain, so an app costs one Core Audio setup instead of one per mouse event. Tearing down at full volume and rebuilding after a process change happen when the user lets go of the slider.
Every AppleScript round-trip in refresh() suspends, and a browser spawns and kills a helper process per tab, so the workspace observers fire it again and again. Several refreshes then interleaved at those suspension points, each enumerating audio processes and tearing down taps for apps the other one had just recorded.
Guard Malloc pinned the crash: setVolume faulted reading a freed page while building a Set from a row's process ids. The array's storage had already been released. The panel drove the sliders with ForEach($vm.rows) and wrote the new volume back through the element binding from inside the drag handler, so SwiftUI's access to the array overlapped the view model's own mutation of it. The rows iterate by value now, MixerSlider keeps the in-flight value in its own state, and every change reaches the view model as a call with the row id instead of a write into its storage.
AppTap documents itself as plain data because it is copied around a nonisolated(unsafe) dictionary and handed to nonisolated teardown code, but it held a [AudioObjectID]. Every crash so far ended in a release of that array's buffer, most recently while tearing a tap down. The set of processes a tap covers is only ever compared for equality, so the struct now carries an order-independent fingerprint instead and has no reference-counted members at all. CATapDescription also gets an array built for it rather than one the caller still holds.
… a11y From the second review pass: - The gain ramp carried its cursor from one AudioBuffer into the next. With non-interleaved stereo that put the second channel at the target value from its first sample, audible as the image jumping sides while a slider moves. Each buffer is one channel of the same frames, so all of them now ramp from the same starting gain. - Retired tap states were kept for the life of the process. They are now freed once 32 further taps have been torn down, which still puts many device teardowns between the last possible callback and the free. - The custom slider is reachable by VoiceOver and the keyboard, and the mute button has a label.
Freeing them after a grace period traded a 16-byte-per-teardown leak for the exact failure that was so hard to find, and a tap is built once per app rather than per interaction, so the leak is a handful of allocations per session. Not worth the risk.
lou1s19
changed the title
Contributor
Author
|
Thanks! Conflicts are sorted, merged instead of rebased so your comment stays put. Both points are in: the mixer is a Testing also turned up heap corruption in the process tap that was in there since my One question: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a per-app sound mixer to OnlySwitch: a new switch that shows a compact
mixer in the switch list popover, modelled on the macOS system Sound panel.
volume slider
How it works
Two mechanisms, chosen automatically per app:
sound volume(0 to 100).a Core Audio process tap (
AudioHardwareCreateProcessTap, macOS 14.4+).macOS exposes no per-app output-level API, so the tap routes the app's audio
through a private aggregate device and scales the samples itself (continuous
gain, of which mute is the
0case). It falls back to silencing on anynon-Float32 stream format. Below macOS 14.4 only the scriptable apps appear.
Where it lives
SwitchType.soundMixerplus aSoundMixerSwitch, so it is enabled inSettings > Customize like every other switch. No bespoke preference and no
settings page of its own. While it is on,
SoundMixerPanelViewsits at the topof the switch list and expands in place, the same shape as
AuthenticatorPanelView. No extra menu bar item.Notes
NSAudioCaptureUsageDescription, because the process tap triggers thesystem audio capture permission prompt on first use.
Localizable.xcstringsin the full set oflanguages the project already ships.
the popover, system volume, Spotify via AppleScript and Chrome via the
process tap, including mute and repeated slider drags.