Hi, I have implemented a custom audio streaming protocol in my iOS app using AVCustomRoutingController to select my custom device. Playback and streaming works. However when the app is the background, it gets killed in a couple of seconds, like if it was not playing audio. My app has the Audio/AirPlay/PIP background mode and can play audio from the background when the route is a normal AVRoute from the system (Speaker/AirPlay/Bluetooth, etc). I tried starting an AVAudioSession (playback category, activated, with and without MPRemoteCommandCenter bindings and with and without populating NowPlayingInfoCenter) was hoping that if that is active, my app won't be killed. But it seems like it does get killed if the app is not producing audio using AudioOutputUnit/AVAudioEngine/AVPlayer. How does one supposed to stream audio from an app in the background using a custom protocol? The infamous "let's play silence to not get killed" solution works, but obviously that can't be the answer.

Hey y'all, I'm new here and in the process of building some audio software. I'm hitting a roadblock trying to incorporate VPIO into audio playback states without it ducking what's currently playing in my DAW. I have a few questions: Can VPIO other-audio ducking be completely disabled on macOS, beyond fixed/minimum? Minimum is not enough for professional audio environments. Is attenuation of an unrelated application routed through a different Core Audio output device expected? Is split-device VPIO—built-in microphone input with Apollo/Universal Audio output—supported? Why can AVAudioEngine.start() succeed while the engine remains stopped and immediately emits a configuration-change notification? Thanks for any insight into this!

Tested iPhone 16 Pro Max running DB2 Since using iOS 27 Developer Beta, Progressive Web Apps (PWAs) and applications using WKWebView that route live streaming audio (such as Icecast/SHOUTcast streams) through the Web Audio API (AudioContext / MediaElementAudioSourceNode for canvas visualizers) experience silent playback freezes during track changes. The JavaScript context remains active, and the HTMLMediaElement reports no errors or pauses, but the low-level system audio daemon (audiod) disconnects. The logs indicate a state desynchronization in MediaToolbox triggered by inline metadata frame updates, coupled with massive sandbox violations. Steps to reproduce: Run a PWA or WKWebView on iOS 27 Developer Beta that loads a live audio stream using an tag. Route the media element into the Web Audio API (e.g., audioContext.createMediaElementSource(audioElement)). Play the stream and lock the screen or let it run in the foreground. Wait for a track transition to occur on the live stream server (which pushes an inline ICY metadata update). Observed Result: Audio instantly goes silent at the track boundary. JavaScript rendering loops remain active, but the stream is dead. List of important errors: MediaToolbox parsing failure: <<<< FigStreamPlayer >>>> fpfs_CacheRenderChain: Caching unexpected mediatype metadata Reasoning: When the stream updates its inline metadata, MediaToolbox (FigStreamPlayer) fails to handle the frame descriptor correctly, halting the stream decoder render chain. Audio engine state desynchronization: <<<< FigStreamPlayer >>>> fpfs_SetRateOnTrack: [...] setting rate on track before it has reached playing state - 4 instead Reasoning: WebKit attempts to keep playing or setting the playback rate, but MediaToolbox fails because the underlying decoder track is stuck in an uninitialized/stalled state (4). System Audio Daemon Disconnection: Subsystem: com.apple.audioanalytics | Process: audiod Reporter disconnected. ( function=sendMessage, reporterID=... ) Reasoning: Because the rendering stream stalled, the system audio daemon (audiod) forcibly severs the audio session connection to the browser container. Massive Sandbox Log Flooding (WebKit.WebContent): Sandbox: com.apple.WebKit.WebContent(2719) deny(1) syscall-unix 179 Reasoning: WebKit's WebAudio thread tries to log trace markers to XNU's kdebug_trace64 (syscall 179) but is blocked by the WebContent sandbox profile, resulting in a loop of thousands of denials that clog the thread. What needs to be fixed: MediaToolbox (FigStreamPlayer): Fix the regression where incoming live stream metadata frames stall the render chain when connected to a Web Audio node. WebKit Sandbox Profiles: Update the iOS WebContent, Network, and GPU sandbox rules to allow necessary tracing/diagnostic calls (syscall-unix 179 and mach-lookup com.apple.diagnosticd) in developer beta builds to prevent thread-blocking loops.

Hey all, here seeking some perspective. I have an audio player app on macOS built on top of AVPlayer, I want to add the ability to scrub the audio, and hear the audio frames based on the playhead's position whether going forwards or backwards. When going backwards, the audio frame should be played in reverse as well. The audio tracks live online and are streamed. I tried playing with AVPlayer.rate, but the time pitch algos built in (.spectral, .varispeed, .timeDomain) all only guarantee up to 32x rate decoding accuracy. So technically, if the user scrubs fast enough, the audio rendered would not necessarily match the playhead's position. My current solution that works is to cache the raw audio bytes and play the appropriate frame when the user starts scrubbing. I decode the audio data manually using AudioToolbox's AudioFileOpenWithCallbacks into an AVAudioPCMBuffer, then pass it into AVAudioEngine+AVAudioPlayerNode combo. The problem with that is that means I need to cache this audio data myself (remember this is a stream), and since I don't have access to AVPlayer's own cache I need to also download it myself... which means two downloads for the same track which is less than ideal. This lead me to take it a step further and hijack AVPlayer's download process by implementing AVAssetResourceLoaderDelegate, that way AVPlayer and my audio scrubbing cache are both fed from the same source. Now... I feel like I went down a bit of a rabbit hole here. At the end of the day I simply want accurate audio scrubbing in both directions, while keeping in mind I want the audio snippets to play in reverse when the user goes backwards. Is there really no way to do this that's more "vanilla"? Am I missing something obvious? Genuinely open to any and all suggestions. Thanks.

Title AVAudioSession microphone recording changes Bluetooth audio route in vehicle Hi everyone, I’m developing an iOS app called HearSave to help drivers safely remember and save songs they hear while driving. The app performs a very simple task: the user presses a button, the app records a short audio sample for music recognition, then immediately stops recording. I’m trying to understand whether the behaviour I’m seeing is an expected limitation of iOS audio routing or whether there is a better AVAudioSession configuration. Test setup iPhone connected to a vehicle via Bluetooth. Vehicle playing DAB radio. App requests microphone access and starts recording. Recording lasts approximately 7 seconds. Behaviour observed As soon as recording begins: The vehicle changes into a voice-call style audio route. DAB audio becomes muted. The vehicle’s volume control changes to voice volume. When recording finishes, the radio does not automatically recover until the user manually changes the audio source away from DAB and back again. I’ve experimented with several Expo Audio / AVAudioSession configurations, including releasing the audio session immediately after recording and adjusting audio session options, but the behaviour remains the same. My questions Is this expected behaviour when an iOS app starts microphone recording while connected to a vehicle over Bluetooth? Is there an AVAudioSession configuration that allows brief microphone capture without causing the vehicle to switch audio routes? Is it possible to explicitly use the iPhone’s built-in microphone while remaining connected to the vehicle via Bluetooth? If this behaviour is unavoidable over Bluetooth, is this also expected behaviour for native CarPlay apps, or are different audio routing capabilities available to CarPlay applications? Any guidance or documentation would be greatly appreciated. Thank you.

On iOS/macOS 26, CNAssetSpatialAudioInfo(asset:) and CNAssetSpatialAudioInfo.assetContainsSpatialAudio(asset:) accept a spatial capture only when its spatial track is APAC-encoded which AVCaptureMovieFileOutput produces when the video codec is HEVC. An otherwise-identical ProRes capture, whose spatial track is LPCM (4-channel First-Order Ambisonics, kAudioChannelLayoutTag_HOA_ACN_SN3D | 4), is rejected with CNCinematicErrorDomain code 3 (CNCinematicErrorCodeIncomplete) "no eligible audio tracks in asset". This reproduces with Apple's own SpatialAudioCLI sample run on Apple's own stock iPhone captures, so it appears to be a property of the format/API rather than my code. I'd like to confirm whether this is intended, and find a supported way to obtain Audio-Mix-eligible spatial audio while still recording ProRes video (we use Apple Log/ProRes for color grading). Respectively, is wiring a manual AVAssetWriter setup the only way to manage spatial audio and ProRes video? Eligibility appears to require an APAC-encoded, exactly-4-channel FOA track. Because AVCaptureMovieFileOutput only writes APAC audio for HEVC (ProRes forces LPCM), ProRes spatial captures are never eligible — including Apple's own ProRes stock captures, which SpatialAudioCLI also rejects. Key finding: eligibility seems baked into the native APAC bitstream Starting from an eligible HEVC/APAC file, I used AVAssetReader/AVAssetWriter to re-encode only the FOA track (APAC → LPCM → APAC), leaving the AAC stereo track, the HEVC video, and the timed-metadata track untouched. The structurally-identical output is then rejected (code 3). Preserving the cinematic-audio metadata track is not sufficient. Re-encoding the APAC itself loses eligibility. This suggests the mix metadata that gates eligibility is carried inside the APAC bitstream and is produced only at capture time. Questions Is it intended that ProRes (LPCM FOA) spatial captures are not Audio-Mix-eligible via CNAssetSpatialAudioInfo, while HEVC (APAC FOA) captures are? Is this documented? Where exactly is the eligibility metadata stored — in the APAC bitstream, or in the cinematic-audio timed-metadata track (Re-encoding the APAC while preserving that metadata track still loses eligibility)? Is there any supported way to make an existing LPCM/ProRes FOA capture eligible after the fact (a transcode/encode path that produces the required APAC), or is native capture the only source? Any guidance, or a pointer to documentation, would be greatly appreciated. Thank you. Environment iPhone 16 Pro Max, iOS 26.x; macOS 26.2; Xcode 26.2.

I'm building a virtual audio device using the HAL Plugin (AudioServerPlugin) API on macOS. The plugin loads correctly, WriteMix is called with non-zero audio data, but Plugin_StartIO is never called from my app's AUHAL input client. Environment: macOS 26.5 Xcode (latest) Bundle ID: com.private.SubON Plugin installed at: /Library/Audio/Plug-Ins/HAL/SubONHALPlugin.driver What works: Plugin loads and is visible as "SubON Virtual Device" Plugin_AddDeviceClient is called with bundleID=com.private.SubON WriteMix is called with non-zero maxSrc values (audio is reaching the plugin) AUHAL setup completes: EnableIO input=1 output=0, CurrentDevice set correctly, AudioUnitInitialize succeeds pre-start readback confirms: currentDevice matches, enableIOIn=1 What doesn't work: Plugin_StartIO is never called from the SubON.app input client WillDoIOOperation is never called ReadInput is never called maxAmplitude in the input tap is always 0.0 AUHAL setup code (Swift): AudioUnitUninitialize(auhal) AudioUnitSetProperty(auhal, kAudioOutputUnitProperty_EnableIO, kAudioUnitScope_Input, 1, &one, size) AudioUnitSetProperty(auhal, kAudioOutputUnitProperty_EnableIO, kAudioUnitScope_Output, 0, &zero, size) AudioUnitSetProperty(auhal, kAudioOutputUnitProperty_CurrentDevice, kAudioUnitScope_Global, 0, &deviceID, size) AudioUnitInitialize(auhal) HAL Plugin — WillDoIOOperation: outWillDo = true; outWillDoInPlace = true; Returns true for both ReadInput and WriteMix. Observation: Even when selecting "SubON Virtual Device" as the system input device in System Settings, Plugin_StartIO is still never called. Any ideas what could prevent Plugin_StartIO from being called despite AUHAL configuration appearing correct?

I have an AUv3 plug-in that works on both iOS and macOS. Some users have complained that after they create a track in Logic Pro (on either iPad or Mac version) and insert my plug-in as an instrument, the track always shows "Untitled" instead of the name of the active preset. Even if the user changes the factory preset, it still says "Untitled". I started debugging my AUv3 API usage for presets, specifically currentPreset and factoryPresets and tried pretty much everything with no success. For example, I tried overriding and not overriding currentPreset, and I tried issuing KVO for currentPreset. But Logic Pro still shows "Untitled" in all cases. In the following screenshot, I'm selecting a factory preset using Logic's interface. Here we see the factory preset is selected and diplayed using the UI of my plug-in, but Logic's interface is still showing Untitled. I noticed AUv2 plug-ins don't seem to suffer from this issue. For example, FabFilter Pro-Q 3 doesn't expose its factory parameters, but I can create a custom preset inside it or load a factory preset and Logic's interface will display the name of the plug-in. I'm assuming the v2 API kAudioUnitProperty_PresentPreset doesn't suffer fron this issue? Here's Logic Pro showing Pro-Q 3's custom preset name I created using the plug-in interface. Is there a solution to this? Or is this a bug? And then whose bug is it Logic's or Core Audio?

Hi everyone, We are the engineering team behind an enterprise communications application for macOS. We are experiencing a critical crash on macOS 26 that did not occur on any previous macOS version. We are seeking clarification from Apple engineers or anyone who may have insight into this behaviour. Environment Architecturex86_64macOS26.4.1 (25E253)HardwareMac15,13 (MacBook Pro)ExceptionSIGILL / ILL_ILLOPCCrashed ThreadThread 0 (Main Thread)TriggerPlaying a notification sound via NSSound during an incoming call Crash Stack 0 caulk consolidating_free_map::maybe_create_free_node + 119 ← SIGILL 1 caulk tiered_allocator + 1469 2 caulk exported_resource::do_allocate + 15 3 AudioToolboxCore EABLImpl::create + 204 4 CoreAudio AUNotQuiteSoSimpleTimeFactory + 33267 8 AudioToolboxCore AudioUnitInitialize + 189 9 AudioToolbox XAudioUnit::Initialize + 19 10 AudioToolbox MESubmixGraph::initialize + 125 11 AudioToolbox MESubmixGraph::connectInputChannel + 1172 12 AudioToolbox MEDeviceStreamClient::AddRunningClient + 509 15 AudioToolbox AudioQueueObject::StartRunning + 194 16 AudioToolbox AudioQueueObject::Start + 1447 22 AudioToolbox AQ::API::V2Impl::AudioQueueStartWithFlags + 805 23 AVFAudio AVAudioPlayerCpp::playQueue + 354 24 AVFAudio AVAudioPlayerCpp::DoAction + 134 25 AVFAudio -[AVAudioPlayer play] + 26 26 AppKit -[NSSound play] + 100 27 Our App -[AudioHelper tryToStartSound:ofType:] + 569 28 Our App block_invoke + 59 Behaviour Difference Between macOS Versions The exact same code path that triggers this crash on macOS 26 works without any issue on macOS 14 and macOS 15 — no crash, no warning, no log output of any kind. The crash occurs inside Apple's private caulk memory allocator during CoreAudio audio engine initialisation, triggered by a call to [NSSound play]. The SIGILL / ILL_ILLOPC at maybe_create_free_node + 119 suggests a hard ud2 trap — an intentional abort guard inserted at compile time. This strongly suggests that something changed in macOS 26 within NSSound / CoreAudio / caulk that causes this code path to fail in a way it previously did not. Questions We have the following specific questions: Was there a deliberate threading policy change in NSSound / CoreAudio in macOS 26? Is the SIGILL in caulk::consolidating_free_map::maybe_create_free_node an intentional thread-affinity assertion introduced in macOS 26? Are there any other NSSound / AVAudioPlayer / AudioQueue APIs that have similarly tightened their requirements in macOS 26 that we should be aware of? Is there a migration guide, release note, or WWDC session that covers CoreAudio changes in macOS 26 that we may have missed? Has anyone else in the developer community encountered a similar SIGILL crash in caulk on macOS 26 during audio playback?

Product: macOS Version: macOS 26.4.1 (25E253) Area: Audio / AVFoundation / AudioToolbox Summary: We are observing a reproducible crash during audio playback initialization in our macOS application on Apple Silicon systems running macOS 26.4.1. The crash occurs inside Apple audio frameworks while creating an AudioQueue through AVAudioPlayer/NSSound APIs. Environment: Application: Avaya Workplace 3.41.0 Hardware: Apple Silicon (Mac14,7) OS: macOS 26.4.1 Application architecture: x86_64 running under Rosetta Frameworks involved: AppKit (NSSound) AVFAudio AudioToolbox caulk Crash Type: SIGILL (ILL_ILLOPC) Observed Stack: -[NSSound play] AVAudioPlayer play AudioQueueNewOutput AudioConverterNewWithOptions caulk::alloc::consolidating_free_map::maybe_create_free_node Details: The crash occurs while attempting to start ringtone/notification playback from the application. The failure happens during AudioQueue initialization before actual playback begins. The crashing thread consistently shows: caulk AudioToolboxCore AudioToolbox AVFAudio AppKit Application audio helper We also observed similar AudioQueue initialization stacks on multiple threads, which may indicate concurrent audio queue initialization. Questions: Is there any known regression in AudioToolbox/AVFAudio/caulk on macOS 26.4.1 affecting x86_64 applications running under Rosetta? Are there known limitations or unsupported scenarios involving AudioQueue creation from Rosetta-translated applications? Are there recommended alternatives or mitigations for NSSound/AVAudioPlayer usage on macOS 26? Reproduction: Launch application on Apple Silicon Mac Trigger ringtone/notification playback Application intermittently crashes during AudioQueue initialization Additional Notes: Crash is intermittent but reproducible in customer environments. The application currently uses NSSound/AVAudioPlayer for ringtone playback. We are also investigating whether concurrent sound initialization may contribute to the issue.

USB cameras, microphones, HDMI capture cards, and audio interfaces are supposed to "just work" on macOS. In reality, it's often difficult to quickly access or monitor them without opening large and complicated software. Sometimes you simply want to see whether a USB camera is active. Sometimes you want to check an HDMI source connected through a capture card. And in other cases, you may want to use a Mac mini without a dedicated monitor by viewing its HDMI output through a USB capture device directly on another Mac. macOS supports many modern USB AV devices out of the box, but it surprisingly lacks a simple built-in utility for live monitoring and recording. Most users end up using oversized streaming or editing applications just to preview a video signal or monitor audio input. That becomes especially noticeable with: USB webcams HDMI capture adapters USB microphones audio interfaces secondary computers headless Mac mini setups A lightweight monitor utility is often much more practical when you only need real-time access to a device, want to record a stream, or quickly switch between multiple AV inputs. That's one of the reasons I built AV Monitor Pro  -  a native macOS app designed for monitoring and recording connected audio/video devices in real time. It can preview USB cameras, capture cards, microphones, and HDMI sources with minimal setup, and it's especially useful for workflows like running a Mac mini without a monitor, monitoring external devices, or recording live AV input directly on macOS.

Summary Using AudioHardwareCreateProcessTap + AudioHardwareCreateAggregateDevice for system audio capture. During long sessions, the AudioDeviceIOProc callback continues firing normally but every PCM sample is exactly 0.0f — while the system is producing audible output. Environment Field Value macOS 26.5 Beta Hardware MacBook Air (M2) API AudioHardwareCreateProcessTap + AudioHardwareCreateAggregateDevice Tap CATapDescription, processes = [], .unmuted, private Format 48,000 Hz, Float32, interleaved stereo Aggregate anchor kAudioAggregateDeviceMainSubDeviceKey = current default output UID Observed behavior After running normally for several minutes, the stream transitions into an all-zero state: AudioDeviceIOProc continues to fire at expected cadence Frame count, timestamps (mHostTime, mSampleTime), and mDataByteSize all look normal AudioBufferList pointers are valid Every sample in every buffer is exactly 0.0f Other apps are still producing audible output through the same output device The condition may self-recover or persist until the session is stopped Confirmed via RMS logging both inside the IOProc and after the ring buffer consumer — data is zero on delivery, not introduced downstream. Example: 51-minute session on MacBook Air M2 Segment 1 (~7 min): Three all-zero periods: 60 s, 53 s, 141 s. Real PCM briefly returned between them. Segment 2 (~44 min): Two all-zero periods: 16 min 3 s, 3 min 8 s. IOProc cadence, timestamp deltas, default output UID, and kAudioDevicePropertyDeviceIsRunningSomewhere all remained normal throughout. What I have ruled out Actual silence: User was in an active video call and could hear participants through the output device. Default output device change: Monitored kAudioHardwarePropertyDefaultOutputDevice — no change during affected periods. IOProc stall: Heartbeat and kAudioDevicePropertyDeviceIsRunningSomewhere remained normal. Aggregate device destroyed: AudioObjectGetPropertyData on the aggregate UID continued returning the expected device. Tap descriptor misconfiguration: The same tap produces valid PCM earlier in the same session, so this is not a startup-time issue. Why detection is hard All-zero buffers from a broken tap are indistinguishable from legitimate silence (muted participant, waiting room, paused media). kAudioProcessPropertyIsRunningOutput reports whether a process has active output IO, not whether it is contributing non-zero samples — a muted Zoom call still reports true. Possible correlations Sample-rate renegotiation on the output device (44.1 kHz ↔ 48 kHz) when another app changes output Bluetooth device state changes (AirPods sleep/wake) where UID stays the same MacBook Air more frequently affected than MacBook Pro Always occurs after extended uptime — first few minutes are consistently clean Current workaround Full teardown and rebuild restores real PCM. Restarting the IOProc alone or recreating only the aggregate device is not reliable — both the Process Tap and Aggregate Device must be destroyed and recreated. 1. AudioDeviceStop 2. AudioDeviceDestroyIOProcID 3. AudioHardwareDestroyAggregateDevice 4. AudioHardwareDestroyProcessTap 5. AudioHardwareCreateProcessTap 6. AudioHardwareCreateAggregateDevice 7. Create + start new IOProc Applying this automatically is risky because it cannot be reliably distinguished from legitimate silence. Questions Expected failure mode? Can a Process Tap continue delivering zero-filled buffers while the system output is audible? Is this expected under certain device or routing conditions? Detection signal? Is there any HAL property, notification, or diagnostic counter that distinguishes "sources are genuinely silent" from "the tap data path has stopped receiving the real mix"? Targeted recovery? Is there a supported way to re-anchor or reset the tap data path without destroying and recreating both objects? Full rebuild as intended workaround? If so, it would help to confirm this so developers can converge on a consistent approach. Mixer activity signal? kAudioProcessPropertyIsRunningOutput reflects IO registration, not sample contribution. Is there any AudioProcess property that indicates a process is currently delivering non-zero audio to the system mixer?

Hi everyone, We’re encountering an issue where AudioQueueNewOutput blocks indefinitely and never returns, and we’re hoping to get some insight or confirmation if this is a known behavior/regression on newer iOS versions. Issue Description When triggering audio playback, we create an output AudioQueue using AudioQueueNewOutput. On some devices, the call hangs inside AudioQueueNewOutput and never returns, with no OSStatus error and no subsequent logs. This behavior is reproducible mainly on iOS 18.3. Earlier iOS versions do not show this issue under the same code path. if (audioDes) { mAudioDes.mSampleRate = audioDes->mSampleRate; mAudioDes.mBitsPerChannel = audioDes->mBitsPerChannel; mAudioDes.mChannelsPerFrame = audioDes->mChannelsPerFrame; mAudioDes.mFormatID = audioDes->mFormatID; mAudioDes.mFormatFlags = audioDes->mFormatFlags; mAudioDes.mFramesPerPacket = audioDes->mFramesPerPacket; mAudioDes.mBytesPerFrame = audioDes->mBytesPerFrame; mAudioDes.mBytesPerPacket = audioDes->mBytesPerFrame; mAudioDes.mReserved = 0; } // Create AudioQueue for output OSStatus status = AudioQueueNewOutput( &mAudioDes, AQOutputCallback, this, NULL, NULL, 0, &audioQueue ); code-block The thread blocks inside AudioQueueNewOutput, and execution never reaches the next line. Additional Notes / Observations ASBD is confirmed to be valid Standard PCM output Sample rate, channels, bytes per frame/packet all consistent Same ASBD works correctly on earlier iOS versions AudioQueue is created on a background thread Not on the main thread Not inside the AudioQueue callback On first creation, AVAudioSession may not yet be active setCategory and setActive:YES may be called shortly before creating the AudioQueue There may be a timing window where the session is still activating Issue is reported mainly on iOS 18.3 Multiple user reports point to iOS 18.3 devices Same code path works on iOS 17.x and earlier No OSStatus error is returned — the call simply never returns. Questions Is it expected that AudioQueueNewOutput can block indefinitely while waiting for AVAudioSession / audio route / HAL readiness? Have there been any behavior changes in iOS 18.3 regarding AudioQueue creation or AudioSession synchronization? Is it unsafe to call AudioQueueNewOutput before AVAudioSession is fully active on recent iOS versions? Are there recommended patterns (or delays / callbacks) to ensure AudioQueue creation does not hang? Any insight or confirmation would be greatly appreciated. Thanks in advance!

I just bought a monitor S2725QC from Dell Technologies and isn't fully-integrated with MacOS even though it says on the website it is compatible with MacOS. https://www.dell.com/en-us/shop/all-monitors/sac/monitors/all-monitors/macos-compatible?appliedRefinements=51765 The screen brightness and volume control buttons don't work with the monitors (I have two). What can I do in terms of writing code with Dell Monitor SDK and MacOS Frameworks/Technologies?

Hello, I am developing a macOS app using AudioToolbox's MusicSequence and MusicPlayer APIs to play Standard MIDI Files. The MIDI playback works correctly and I can hear sound from the external MIDI device. However, the user callback registered via MusicSequenceSetUserCallback is never invoked during playback. Details: Callback registration returns no error. MusicPlayer is properly started and prerolled. The callback is defined as a global function with the correct @convention(c) signature. I have tried commenting out MusicTrackSetDestMIDIEndpoint to avoid known callback suppression issues. The clientData pointer is passed and correctly unwrapped in the callback. Minimal reproducible example shows the same behavior. Environment: macOS version: [Tahoe 26.2] Xcode version: [26.2] Is it expected that MusicSequenceSetUserCallback callbacks may not be called in some cases? Are there additional steps or configurations required to ensure the callback is triggered during MIDI playback? Thank you for any advice or pointers. Execute playTest() in the viewDidLoad() method of the ViewController. extension ViewController { private func playTest() { NewMusicSequence(&sequence) if let midiFileURL = Bundle.main.url(forResource: "etude", withExtension: "mid") { MusicSequenceFileLoad(sequence!, midiFileURL as CFURL, .midiType,MusicSequenceLoadFlags()) NewMusicPlayer(&player) MusicPlayerSetSequence(player!, sequence!) MusicPlayerPreroll(player!) let status = MusicSequenceSetUserCallback(sequence!, musicSequenceUserCallback, Unmanaged.passUnretained(self).toOpaque()) if status == noErr { print("Callback registered successfully") } else { print("Callback registration failed: \(status)") } MusicPlayerStart(player!) } else { print("MIDI File Not Found") } } } The callback function was generated by Xcode and defined outside the ViewController. func musicSequenceUserCallback( clientData: UnsafeMutableRawPointer?, sequence: MusicSequence, track: MusicTrack, eventTime: MusicTimeStamp, eventData: UnsafePointer<MusicEventUserData>, startSliceBeat: MusicTimeStamp, endSliceBeat: MusicTimeStamp ) { print("User callback fired at eventTime: \(eventTime)") if let clientData = clientData { let controller = Unmanaged<ViewController>.fromOpaque(clientData).takeUnretainedValue() // Example usage to prove round-trip works (avoid strong side effects in callback) _ = controller.view // touch to silence unused warning if needed print("Callback has access to ViewController: \(controller)") } else { print("clientData was nil") } }