HDMI and DisplayPort audio devices expose no kAudioDevicePropertyVolumeScalar or kAudioDevicePropertyMute, so System Settings disables the volume slider and the media keys do nothing when such a display is the default output. Users end up installing virtual audio drivers or DDC/CI tools, and DDC does not pass through many HDMI paths at all. I wanted to check whether the behavior users expect can be provided with public API only, and it can: AudioHardwareCreateProcessTap with a CATapDescription that excludes the app's own process and uses CATapMutedWhenTapped, a private aggregate device with the tap as a sub-tap and the display as the main sub-device, and an IOProc that scales the tap input into the device output. The volume keys are captured with a session-level CGEvent tap. Source (three files, Swift and Objective-C): https://github.com/mevlut-geredeli/MonitorKeys Observations that may be useful to others using taps:
- The tap delivers IOProc callbacks only while some process is rendering; at idle there are none. That is expected, not a failure.
- Two process taps on the same device from different processes interfere with each other: AudioDeviceStart blocks until the other tap is torn down.
- The path works inside the App Sandbox with com.apple.security.device.audio-input; no microphone usage string is required for a tap.
Since this is achievable in software, I filed FB24965962 requesting a per-device "control volume in software" option for these outputs, which would remove the need for the tap, the system audio permission and the Accessibility permission. If a Core Audio engineer can comment on whether that is a reasonable direction, I would be glad to test a seed build with this display (ViewSonic VX3276-QHD over HDMI, Mac mini M6, macOS 27.0 26A428).