I am testing SFSpeechRecognizer using the en_US locale. When the iPhone Simulator’s system language is set to Japanese, SFSpeechRecognizer.isAvailable returns false for en_US, so speech recognition is unavailable. As far as I have tested, this issue does not occur on iOS Simulator 26.2 or earlier. Is this a Simulator-specific issue, or is it a behavior change that could also occur on physical devices? Has any additional setup become necessary to use speech recognition in Simulator? I then changed the iPhone Simulator’s system language to English. After doing so, SFSpeechRecognizer.isAvailable returned true for en_US. However, starting a recognition task still failed immediately with kLSRErrorDomain Code=300, “Failed to initialize recognizer.” The following error was returned: Error Domain=kLSRErrorDomain Code=300 "Failed to initialize recognizer" UserInfo={ NSLocalizedDescription=Failed to initialize recognizer, NSUnderlyingError={ Error Domain=kLSRErrorDomain Code=300 "Failed to create recognizer from=/Users/<USERNAME>/Library/Developer/CoreSimulator/Devices/<DEVICE-UUID>/data/private/var/MobileAsset/AssetsV2/com_apple_MobileAsset_UAF_Siri_Understanding/purpose_auto/ c079bfa6b8856202dc8cb2135fef3b06229ced6e.asset/AssetData/mini.json" UserInfo={ NSLocalizedDescription=Failed to create recognizer from=/Users/<USERNAME>/Library/Developer/CoreSimulator/Devices/<DEVICE-UUID>/data/private/var/MobileAsset/AssetsV2/com_apple_MobileAsset_UAF_Siri_Understanding/purpose_auto/ c079bfa6b8856202dc8cb2135fef3b06229ced6e.asset/AssetData/mini.json } } } I have not observed either of these issues on iOS Simulator 26.2 or earlier: With the Simulator language set to Japanese, the en_US recognizer does not become unavailable. When SFSpeechRecognizer.isAvailable is true, recognition does not fail with kLSRErrorDomain Code=300. Environment Xcode: 26.6 (17F113) iOS Simulator 26.5 (23F77), iPhone 17 (A3258J/A) iOS Simulator 26.4 (23E244), iPhone 17 (A3258J/A)

I’m migrating to the new notifications described in Handling audio interruptions. On an iPhone 14 running iOS 27.0.1 (24A446), I call pause() when the system deactivates the session. On .shouldResume, I await successful session.activate() and call record() on the same recorder. It returns true, but the saved file contains only the audio recorded after Siri. To reproduce: record for five seconds, invoke and dismiss Siri, record for another five seconds, then stop and play. The earlier five seconds are missing. A legacy-notification control preserved both portions on the same phone. Is another step required to preserve the recording with the new notifications, or is this a known issue? I found this similar report, although it uses the legacy API. Minimal reproduction Built with Xcode 27.1. Create a SwiftUI iOS app targeting iOS 27, replace its generated App.swift with the code below, and add these Info.plist entries: NSMicrophoneUsageDescription: Test audio recording UIBackgroundModes: an array containing audio import SwiftUI import AVFoundation @main struct RecorderReproApp: App { var body: some Scene { WindowGroup { RecorderReproView() } } } @MainActor struct RecorderReproView: View { private let session = AVAudioSession.sharedInstance() private let file = URL.documentsDirectory.appendingPathComponent("recording.m4a") @State private var recorder: AVAudioRecorder? @State private var player: AVAudioPlayer? @State private var running = false @State private var interrupted = false @State private var status = "Ready" var body: some View { VStack(spacing: 24) { Button("Start") { Task { await start() } }.disabled(running) Button("Stop") { running = false interrupted = false recorder?.stop() status = file.path }.disabled(!running) Button("Play") { do { player = try AVAudioPlayer(contentsOf: file) status = "Saved duration: \(player!.duration) seconds" player?.play() } catch { status = error.localizedDescription } }.disabled(running) Text(status) } .padding() .task { for await notification in NotificationCenter.default.notifications( named: AVAudioSession.didBecomeInactiveNotification, object: session ) { guard running, let context = notification.userInfo?[AVAudioSession.deactivationContextKey] as? AVAudioSession.DeactivationContext, context.source == .system else { continue } recorder?.pause() interrupted = true status = "Interrupted" } } .task { for await notification in NotificationCenter.default.notifications( named: AVAudioSession.resumptionRecommendationNotification, object: session ) { guard running, interrupted, let context = notification.userInfo?[AVAudioSession.resumptionContextKey] as? AVAudioSession.ResumptionContext else { continue } guard context.recommendation == .shouldResume else { interrupted = false continue } do { guard try await session.activate(), running, interrupted else { continue } status = "Resumed: \(recorder!.record())" interrupted = false } catch { status = error.localizedDescription } } } } private func start() async { guard await AVAudioApplication.requestRecordPermission() else { return } do { try session.setCategory(.playAndRecord) guard try await session.activate() else { return } recorder = try AVAudioRecorder(url: file, settings: [ AVFormatIDKey: kAudioFormatMPEG4AAC_HE, AVSampleRateKey: 44_100, AVEncoderBitRateKey: 32_000, AVNumberOfChannelsKey: 2 ]) running = recorder!.record() status = "Recording: \(running)" } catch { status = error.localizedDescription } } }

Hi, I believe I have found a Core Audio regression in macOS 27. This exact hardware configuration worked correctly on macOS 26, and the issue started immediately after upgrading to macOS 27. Hardware: Mac mini M2 2 × MSI MP243X monitors Monitor 1 connected via HDMI Monitor 2 connected via DisplayPort Both monitors expose a 2-channel audio output to macOS On macOS 26: I used Audio MIDI Setup to create a Multi-Output Device containing both MSI MP243X audio outputs. Audio played simultaneously through both monitors without any issues. On macOS 27: Both audio devices are still detected correctly and both work perfectly when selected individually: HDMI only: WORKS DisplayPort only: WORKS HDMI + DisplayPort simultaneously: FAILS This is reproducible even immediately after a full reboot. When I create a new Multi-Output Device containing both MSI outputs and select it as the system output, audio playback cannot start. For example: afplay /System/Library/Sounds/Glass.aiff returns: Error: AudioQueueStart failed ('stop') I captured Core Audio debug logs while reproducing the problem. Core Audio initially reports that StartIO succeeded, but the physical display audio device then fails to establish a timeline. Relevant log messages include: HALS_IOEngine2::_StartIO succeeded Device 3669B540-0000-0000-2623-0104A5351D78 is not running. could not establish a timeline after waiting 10000000 microseconds stopping with error 1937010544 StartIOThread: the IO thread failed to start, Error: 1937010544 I have already tested the following: Both devices at 44.1 kHz / 24-bit Both devices at 48 kHz / 16-bit Recreating the Multi-Output Device from scratch Using the HDMI device as clock source Using the DisplayPort device as clock source Different drift correction configurations Restarting coreaudiod Full macOS reboot Testing both outputs individually immediately after reboot Alternative multi-device audio routing software The behavior is always reproducible. Each MSI MP243X audio endpoint works correctly by itself. The failure only occurs when both HDMI and DisplayPort audio endpoints are opened simultaneously. system_profiler correctly detects both devices at 48 kHz: MSI MP243X Output Channels: 2 Current Sample Rate: 48000 Transport: HDMI MSI MP243X Output Channels: 2 Current Sample Rate: 48000 Transport: DisplayPort This does not appear to be a problem with either monitor or connection individually, because both outputs continue to work independently. The important difference is the macOS version: macOS 26: HDMI + DisplayPort Multi-Output = WORKING macOS 27: HDMI only = WORKING DisplayPort only = WORKING HDMI + DisplayPort Multi-Output = FAILS with AudioQueueStart 'stop' / Core Audio error 1937010544 No hardware, monitor, cable, or connection changes were made between the working macOS 26 configuration and the macOS 27 configuration. This therefore appears to be a regression in the Core Audio/display-audio path introduced with macOS 27 when two display audio endpoints (HDMI + DisplayPort) are opened simultaneously. Has anyone else been able to reproduce this on macOS 27, particularly on Apple Silicon? I can provide the complete coreaudiod logs and run additional Core Audio diagnostics if needed. Additional isolation tests: Both monitors can remain physically connected to the Mac at the same time. With both HDMI and DisplayPort connected: Selecting the HDMI MSI MP243X as the only output works correctly. Selecting the DisplayPort MSI MP243X as the only output works correctly. Opening both audio endpoints simultaneously causes the failure. Therefore, simply having both displays connected does not trigger the issue. The failure appears specifically when Core Audio attempts to run both display-audio endpoints at the same time. I also tested this using third-party multi-device audio routing implementations instead of relying only on Audio MIDI Setup. The same behavior occurs: either MSI MP243X can be opened and used independently, but attempting to route audio to both devices simultaneously fails. This suggests that the issue is below the Multi-Output Device configuration itself and may be related to starting/synchronizing two display-audio IO engines simultaneously. During the failure, the Core Audio log sequence is particularly interesting: The physical device is detected normally. The audio format is configured successfully. Core Audio reports that StartIO succeeded. The device subsequently reports that it is not running. Core Audio waits 10 seconds for a timeline. Timeline establishment fails. The IO thread terminates with error 1937010544 ('stop'). One captured conversion path was: 2 ch, 48000 Hz, Float32, interleaved -> 2 ch, 48000 Hz, Int16, interleaved so both sides were operating at 48 kHz during this test. Another important observation is that restarting coreaudiod does not resolve the simultaneous-output problem. A complete reboot also does not resolve it: immediately after a fresh boot, before launching any third-party audio-routing software, both physical outputs work individually but a newly created Multi-Output Device still reproduces the failure. This makes the issue highly reproducible on this machine. Minimal reproduction: Boot macOS 27 with both MSI MP243X monitors connected. Open Audio MIDI Setup. Verify both MSI MP243X devices work independently. Set both devices to 48,000 Hz. Create a new Multi-Output Device. Select both MSI MP243X devices. Select the new Multi-Output Device as the system audio output. Run: afplay /System/Library/Sounds/Glass.aiff Expected result: The sound is reproduced simultaneously through both monitors, as it was on macOS 26. Actual result: Error: AudioQueueStart failed ('stop') Switching the system output back to either individual MSI MP243X restores audio playback. The problem can then be reproduced again by selecting the Multi-Output Device.

I have not seen any issues with didActivateAudioSession not getting called by iOS in many many years with many thousands of devices. However with iOS27 beta code I have seen a few times that when making an outgoing call it never gets called. All subsequent outgoing calls fail until I dismiss and relaunch the App.

When wrapping CABTMIDICentralViewController in a UIViewControllerRepresentable and presenting modally, I experience layout crashes since iOS 27. Does anyone have a workaround? import SwiftUI import CoreAudioKit struct BluetoothButton: View { @State var showsBluetooth = false let title = "Check for Bluetooth MIDI Devices" var body: some View { #if os(macOS) Button { let wc = CABTLEMIDIWindowController() wc.showWindow(nil) } label: { label } #else Button { showsBluetooth = true } label: { label } .sheet(isPresented: $showsBluetooth) { BluetoothCentralView() } #endif } var label: some View { Text(title) } } #if os(iOS) struct BluetoothCentralView: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> CABTMIDICentralViewController { return CABTMIDICentralViewController() } func updateUIViewController(_ uiViewController: CABTMIDICentralViewController, context: Context) { } } #endif

Summary On iOS build 24A446, an incoming CallKit VoIP call is reported and answered, but the system never creates or activates the CallKit audio session, so CXProviderDelegate provider:didActivateAudioSession: is never called. Both directions of call audio stay silent. The failure is inside callservicesd / audiomxd, before the app starts its audio unit. Once it starts, later calls from the same processes keep failing until the app process is killed. App and device Bundle ID: us.zoom.videomeetings OS build: 24A446 (iPhone) Log: sysdiagnose_2026.10.16_11-15-45-0700_iPhone-OS_iPhone_24A446 Sample call: 2026-10-15 13:29:06–13:29:22 PDT Processes in that window: Zoom PID 816, callservicesd PID 2474, audiomxd PID 115 How the user hits it The app is not in the foreground. A VoIP push wakes it and we call reportNewIncomingCallWithUUID:update:completion:. The user answers from the system incoming-call UI (phone locked or unlocked). The ringtone plays. After answer there is no call audio. The same failure then happens on later calls, including a call started from inside the app, until the Zoom process is killed. Signing out or rebooting only clears it temporarily. We cannot reproduce it in our lab. It became much more frequent after devices moved to this OS. What the app does We configure one CXProvider (PlayAndRecord is applied when the system activates the session). We fulfill CXAnswerCallAction when the user answers. We start the voice audio unit only from provider:didActivateAudioSession:. We do not call AVAudioSession setActive: during this answered call. Our log line "ZMCallKitManager::didActivateAudioSession" is not present for this call. System log for the sample call 13:29:06 — incoming call reported Zoom log: Provider was asked to report a new incoming call At that moment Zoom's existing primary session is sid:0x7304f, Zoom(816), 'prim', and the app is BackgroundRunning. callservicesd then fails while creating the CallKit session: audiomxd AVAudioSessionXPCServer.mm:231 -[AVAudioSessionRemoteXPCClient createProxySession:reply:] failed due to session lookup failure for SessionID 0x0 callservicesd AVAudioSession_iOS.mm:643 Creating proxy session failed, session ID = 0x0, NSOSStatusErrorDomain -50, "Session lookup failed" audiomxd ServerSessionManager.mm:192 Sibling session creation failed. Source sessionID: 0x0. SessionID is not valid. Source PID: 2474 audiomxd AVAudioSessionXPCServer.mm:1287 Session creation failed callservicesd SessionCore_Create.mm:92 AudioSession creation failed, NSOSStatusErrorDomain 2003329396, "Session creation failed in server" callservicesd Audio session not found for call. Returning nil The ringtone still plays. That audio is callservicesd's own session sid:0x732fa, category Ringtone/Default, which activates at 13:29:06.650. It is not the call session. 13:29:15 — user answers callservicesd: Performing answer request / Perform answer call callservicesd: No provider returned for descriptor callservicesd: Audio session not found for call. Returning nil callservicesd: Answer call action fulfilled callservicesd: Error retrieving AVAudioSession provider with ID 0 Sibling session creation fails again with Source sessionID 0x0, Source PID 2474. The ringtone session is stopped. From 13:29:15 to 13:29:22 there is no "action":"activate" for a CallKit call audio session, and no provider:didActivateAudioSession: notification to Zoom. Zoom's primary session 0x7304f is still inactive. Its category is updated to PlayAndRecord / VoiceChat, but it is not activated while this call is up. 13:29:22 — call ends Provider was asked to report that call ended with reason 2 callservicesd: Setting disconnected reason to remote hangup because ended reason is 2 sid:0x732fa callservicesd going inactive The call lasted about 7 seconds with no call audio session ever created. 13:29:33 — following call, same stuck state About 11 seconds later a CXStartCallAction is fulfilled. Zoom's own session then activates: sid:0x7304f, Zoom(816), 'prim' PlayAndRecord_WithBluetooth / VoiceChat, NonMixable, going active callservicesd still cannot build its session: "No existing proxy AVAudioSession interruption provider for ID 0, creating a new one" Session creation failed in server Error retrieving AVAudioSession provider with ID 0 Audio session not found for call So an app-side setActive: after the failed call does not repair the CallKit provider. The system session id remains 0x0. How often it happens in this sysdiagnose Filtering the archive for the hard failure (not the generic "Audio session not found" line, which also appears on earlier days): "Sibling session creation failed. Source sessionID: 0x0": 93 hits, grouped into 57 bursts First burst: 2026-10-15 09:52:11 PDT Last burst: 2026-10-16 11:14:30 PDT (about a minute before this sysdiagnose was taken) "Error retrieving AVAudioSession provider with ID 0": 34 hits "Session creation failed in server": 93 hits Every one of these sibling-session failures is Source PID 2474. callservicesd stays PID 2474 and audiomxd stays PID 115 across the whole window, including overnight. The bad session id is stuck in those daemons, not in one Zoom call object. There is no log line in this archive showing callservicesd successfully activating a provider audio session for these calls. Request Please confirm this is the known CallKit failure where didActivateAudioSession is not delivered because callservicesd cannot create the audio session (Session lookup failed / Session creation failed in server, session ID 0x0). Related public reports: Feedback FB19429215, "CallKit does not activate audio session after iOS 18.4.1", and the iOS 27 thread "iOS 27 CallKit didActivateAudioSession". DTS previously advised apps not to call setActive: themselves, because the CallKit session has higher priority and an app activation can fail or disturb system state. This log matches that: the session is never created, so there is nothing for the system to activate. Please also advise which of these is safe on 24A446 when provider:didActivateAudioSession: does not arrive: Call CXProvider setConfiguration: again (same configuration) before every reportNewIncomingCallWithUUID:update:completion:. On a timeout, fail the unanswered CXAnswerCallAction so the CallKit state machine resets, without invalidating or recreating the CXProvider. Anything else that clears the stuck session ID 0x0 inside callservicesd without a device reboot. I can provide another sysdiagnose if you need a logging profile installed before the next reproduction.

I'm investigating an intermittent crash in an iOS audio app when launching it through an Inter-App Audio (IAA) host Audiobus and AUM. The crash occurs during the host connection/startup process. The app begins initializing its audio engine, successfully creates and registers an ABAudioSenderPort, starts its output audio unit, and then crashes. Crash details Crash Report Exception: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x50 Backtrace: #0 _dispatch_sync_f #1 caulk::concurrent::details::dispatch_receiver::~dispatch_receiver #2 std::__1::__shared_weak_count::__release_shared #3 caulk::concurrent::messenger::~messenger #4 CADeprecated::CAAutoDelete<caulk::concurrent::messenger>::set #5 AURemoteIO::IPC_Uninitialize #6 AURemoteIO::IPC_Uninitialize #7 AUWrappedOutputUnit::AUUninitialize #8 _XUninitialize #9 IPCAudioUnit_server #10 dispatch_mig_server #11 _dispatch_client_callout #12 _dispatch_continuation_pop #13 _dispatch_source_latch_and_call #14 _dispatch_source_invoke #15 _dispatch_lane_serial_drain #16 _dispatch_lane_invoke #17 _dispatch_root_queue_drain_deferred_wlh #18 _dispatch_workloop_worker_thread #19 _pthread_wqthread Repro: Quit Audiobus completely. Relaunch Audiobus. Launch the app from Audiobus. The app begins initialization, but crashes during or shortly after the initial host connection. Interestingly, if Audiobus remains open and I attempt to launch the app again, the crash doesn't appear to occur. Reloading the app via AUM is also reproducing the crash. A number of other apps are able to launch via Audiobus, so I think it must be how we are initialising our engine, but I haven't been able to find where we are going wrong. The app configures its audio session as follows: Category: AVAudioSessionCategoryPlayback Mode: AVAudioSessionModeDefault Preferred sample rate: 48000 Hz Preferred I/O buffer duration: approximately 5.3 ms Reported buffer size: 256 frames Input channels: 0 Output channels: 2 Audio-unit initialization The engine creates and initializes its audio unit successfully: AudioComponentInstanceNew: status = 0 AudioUnitInitialize: status = 0 AudioOutputUnitStart: status = 0 The app then creates an ABAudioSenderPort, configures its client format, and registers it with ABAudiobusController. These operations also complete successfully. The engine's RemoteIO audio unit and the sender port's audio unit are separate instances. I haven't yet worked out which instance is being uninitialized when the crash occurs. This seems to be happening across multiple iPhone and iPad models, back to at least iOS 17, and my test environment, Xcode 26.6 and iPadOS 26.5.2. Questions Has anyone encountered this caulk::concurrent::messenger::~messenger / AURemoteIO::IPC_Uninitialize crash when using IAA, Audiobus, AUM? Could this indicate a race or invalid lifecycle transition in Apple's RemoteIO/IAA IPC implementation? Are there known requirements concerning the order of audio-unit initialization, sender-port registration, host connection, and uninitialization that could explain this behavior? What additional diagnostics would help determine which audio-unit instance is being uninitialized and what triggers the failure? Any suggestions or reports of similar behavior would be greatly appreciated.

Hi everyone, I'm building a tvOS app that shows analog VU meters for the music playing, in the style of vintage hi-fi amplifiers and tape decks. It works well with local and network files played through AVAudioEngine, where I can tap the signal and measure real levels. With Apple Music, though, there's no way to get even basic level information. The content is DRM-protected, SystemMusicPlayer and ApplicationMusicPlayer render audio outside the app's audio graph, and MusicKit has no metering API. My current workaround is to analyze the song's 30-second preview and replay its level envelope in a loop. It looks plausible, but it isn't in sync with the actual music. I filed FB25234486 asking for a read-only metering API on MusicPlayer, similar to what AVAudioPlayer already offers: let rms = musicPlayer.averagePower(forChannel: 0) // dBFS let peak = musicPlayer.peakPower(forChannel: 0) // dBFS This wouldn't expose any audio samples: just one RMS and one peak value per channel, at a low, capped rate (around 30 Hz). Those numbers can't be turned back into audio, so content protection wouldn't be weakened, and the values could be computed inside the system's playback process. It would make a number of use cases possible: VU and peak meters, audio-reactive visualizers, ambient lighting synced to the music (HomeKit, smart lights), loudness displays, and accessibility features such as visual feedback of the music for hard-of-hearing users. If you need this too, please file your own feedback and mention FB25234486. Duplicate reports help Apple gauge demand. And if anyone has found a supported way to get playback levels from MusicKit today, I'd love to hear about it. Thanks!

Hey everyone, I need to reorder a four-song Apple Music application queue while keeping the same selected occurrence, playback time, and playing/paused state. I reproduced two distinct failures in a standalone app without persistence or synchronization. I do not yet know whether these failures have a common cause. Device: iPhone 16 Pro, iOS 27.0.1 (24A446), built-in audio. Music authorization and catalog subscription checks succeed. Four distinct catalog songs resolve successfully in the Japanese storefront, in the order A, B, C, D. These letters are anonymized labels for the songs used in the measured runs; the actual catalog IDs are omitted from this public post. This does not establish that the issue occurs with every four-song selection. Repeat and shuffle are off. MusicKit reorder after a stable paused baseline Install ApplicationMusicPlayer.Queue once, starting at song D. Play once, then pause after several seconds; verify all four entries and unchanged Current/time for over ten seconds. Move the non-Current prefix in one operation: queue.entries.move(fromOffsets: IndexSet(integersIn: 0..<3), toOffset: 4) Expected: [A,B,C,D*] becomes [D*,A,B,C], retaining Current and elapsed time. RemotePlayerService instead terminates with SIGABRT during queue modification. The exception stack includes _componentsForContentItemID: and _qfa_performInsertPlaybackContext:atPosition:afterContentItemID:sectionIdentifier:actions:completion:. The client then hangs in synchronous XPC connection establishment on main. This also occurred with all app-initiated post-move SDK reads suppressed; the service report predates the first scheduled read. A direct Current move 3→0 produced a matching service exception stack in a separate run. MediaPlayer alternative fails before any reorder Using applicationQueuePlayer instead, set one MPMusicPlayerStoreQueueDescriptor for the same songs A–D with startItemID set to song D's actual catalog ID. Set repeat/shuffle off, activate an AVAudioSession playback/default session and call play once. Immediately call performQueueTransaction:completionHandler: with an empty transaction block. Completion is on main and error is nil. All queue access is synchronous inside that callback. The relevant Objective-C read order is: id raw = queue.items; NSUInteger currentIndex = player.indexOfNowPlayingItem; id current = player.nowPlayingItem; NSArray *items = raw; // raw was checked to be a nonnil NSArray NSUInteger count = items.count; for (NSUInteger i = 0; i < count; ++i) { id item = [items objectAtIndex:i]; if (!item) { /* record index and end observation */ break; } // Validate MPMediaItem and copy its nonempty playbackStoreID. } count was 4, currentIndex was 2, current was nonnil, and elements 0 and 1 validated. objectAtIndex:2 returned nil. No queue object escapes the callback. The guard ended the read with audio continuing and UI responsive. An earlier Swift queue.items.map observation crashed in Swift element dynamic casting. This newer result does not establish which song occupies returned index 2. There was no queue mutation or repeat read in this MediaPlayer trial. Both startup sequences logged "ping did not pong"; the MusicKit reorder trial subsequently reached the stable paused baseline. I cannot rule out startup's contribution. I have not established the behavior on another device/OS. Questions Is modifying entries the supported way to reorder the full application queue across Current while retaining its occurrence and continuous audio? For MediaPlayer, is a successful read-only transaction completion expected to provide a fully readable nonnull items array? Is there a documented readiness condition before enumeration that this sequence is missing? If MediaPlayer transactions are a suitable alternative, how should callers target duplicate occurrences (not just song IDs) for removal/insertion? I can provide a minimal project and the two separate failure reports through Feedback Assistant. Which component and additional diagnostics would be most useful? No Feedback ID exists yet.

We develop Donuts, an AUv2 MIDI processor (aumi), using JUCE 8.0.12 on Apple Silicon. Test environment: Logic Pro 12.4 (6707), macOS 27.0.1 (26A434). Instances within one Logic project need to share an editable chord chart automatically, while retaining independent voicing/output settings. Instances in different open projects must keep separate charts, without manual pairing. Is there a supported Logic/AU API that supplies a project-scoped identity or ownership context to an AU MIDI FX instance? If not, does Logic guarantee that an AUHostingService process cannot contain live instances from different projects, including during project switching, loading and recovery? Can one project's instances be distributed across more than one hosting process? Do these guarantees depend on Logic version or hosting configuration? We completed labelled native captures on 18 October 2026 using a diagnostic observer at the AudioUnitSDK AUMethodSetProperty entry dispatcher, after the original setter returns. This includes properties handled by AUBase before the JUCE SetProperty override. It records status, selected property metadata and top-level restored state key names/types; it does not dereference opaque host client data. Automatic AU sharing remains disabled. Observed in the corrected 0.2.40 probe: Original track and duplicate in project A were both in PID 27015. Each received a different HostCallbackInfo.hostUserData value and a different ContextName. We compare process-local hashes, not dereferenced pointers. Both received all four transport callback functions; AUHostIdentifier matched within the process. No NickName assignment was observed before the captures. There were no recorded capture losses. Keeping A's project window open and opening a separate project B unloaded both A processors at 18:12:27, reaching a live count of zero. B's fresh instance loaded in PID 27146 at 18:12:50. A previous labelled project-switch test also unloaded the original processors and loaded the new project's instance in a different process. These observations do not establish a general isolation guarantee. Restored state in A contained data, jucePluginState, manufacturer, name, subtype, type and version. B was a fresh insertion with no state restore. Payload contents were not recorded. Saved plug-in IDs alone cannot distinguish ownership when tracks, presets or projects are duplicated. ContextName and hostUserData equality do not group the original and duplicate in this test. We have not established a project-ownership contract for either. The application identity also does not distinguish projects. Please advise on the supported mechanism or hosting-process ownership and lifetime guarantees for this use case. Our aim is automatic discovery without ever combining charts from different projects. Local evidence: context-evidence-0.2.40/01-original-and-duplicate and context-evidence-0.2.40/02-separate-project contain raw captures, lifecycle logs, SHA-256 hashes and observations. Nothing has been submitted externally.

I am looking for the documented observability boundary of Audio Unit version 3 MIDI output in Logic Pro. When an Audio Unit submits events through AUMIDIOutputEventBlock, is there a supported public interface or documented ordering guarantee that can establish that all events accepted for a particular output route and stopped session have been processed, with none still pending for later delivery? I mean that component's route, not unrelated tracks or every queue in the host. I have reviewed the public documentation for AUMIDIOutputEventBlock, scheduleMIDIEventBlock/AURenderEvent, render observers, transportStateBlock, contextPresentationLatency, tailTime, and AUMessageChannel. I have not found a route-completion acknowledgment. A successful submission callback, stopped transport, received event list, or finite silent recording seems to describe a different observation point from completion of all pending delivery. Does Logic support a documented AUMessageChannel protocol or other public mechanism for this purpose? If so, which Logic/macOS versions support it, what is the completion notification's scope and clock domain, and what are its ordering and caller-thread requirements? In particular, does it remain available if transport stops and no final render callback occurs? If receiving every expected event at a downstream Audio Unit can establish completion instead, what documented guarantee rules out later delivery or duplicates from the same stopped session? Instrument processing, effects tails, and actual hardware playback are separate observation boundaries; I am not treating their completion as implied by MIDI receipt. Confirmation that this internal state is not exposed by a supported public interface would also be useful. This is an API-capability question, not a report of an observed Logic defect. I am not seeking private APIs, confidential implementation details, queue flushing, process instrumentation, virtual drivers, or audio-device reconfiguration. No project source, logs, recordings, or account information are included.

I’m building a personal iPhone app that organizes my music library. When I tap an album in my app, I want Apple’s Music app to open directly to that album’s page in Library, showing the tracks synced from my computer. My app can already read the albums and their tracks using MusicKit. I’ve tried normal Apple Music sharing links, but those open the catalog version of the album. I need the page I see when I find the album through Library in the Music app. Starting or changing playback is fine, but the album page must appear. Only starting the music or opening Now Playing would not be enough. Is there a supported API or link format that can do this? A documentation link or a small code example would be helpful.

Hi everyone, I’m developing a native Apple TV application using MusicKit for Swift. The app provides a custom interface for browsing and playing the user’s personal Apple Music library. The application was working correctly for several months, but recently certain songs from the user’s personal library have stopped playing. I’ve been investigating this issue extensively and have reproduced it in a completely separate, minimal tvOS test application. The issue I retrieve songs using MusicLibraryRequest() and play them using ApplicationMusicPlayer. Some songs play successfully, while others consistently fail during playback preparation with: `MPMusicPlayerControllerErrorDomain Code=6 "Prepare to play failed"` The underlying errors include : NSCocoaErrorDomain Code=4099 Example of a failing song Michael Jackson — Bad (2012 Remaster) Library song ID: i.ldDOAp0UrAa62J Successfully retrieved using MusicLibraryRequest() Fails when queued with ApplicationMusicPlayer Also fails with SystemMusicPlayer Example of a working song Harry Nilsson — Everybody’s Talkin’ (1971 Mix) Library song ID: i.WmYQp9PcdZ4Y0E Retrieved using the exact same MusicLibraryRequest() Successfully plays using ApplicationMusicPlayer Both songs have library identifiers beginning with i.. What I’ve tested ApplicationMusicPlayer with prepareToPlay() followed by play(). SystemMusicPlayer with the same library song. Direct play() without explicitly calling prepareToPlay(). Retrieving songs directly using MusicLibraryRequest(), rather than accessing them through albums. A completely separate minimal tvOS application. An older version of my application’s code, recompiled using the current Xcode version. The issue persists across these tests. Interestingly, the corresponding Apple Music catalog song plays successfully when retrieved through MusicCatalogSearchRequest. However, replacing library songs with catalog equivalents is not an acceptable solution because the application needs to support users’ actual personal libraries, including imported music. Important observation The exact same failing song plays correctly on the same Apple TV and Apple Music account in: The official Apple Music application. Sleeve, another third-party Apple TV music player. This suggests that the song itself is playable and that another third-party application can successfully initiate playback. Environment Platform: tvOS Device: Physical Apple TV Framework: MusicKit for Swift Apple Music authorization: Granted MusicKit App Service: Enabled Signing: Automatic, using a paid Apple Developer account Question Is there a known issue with resolving or playing certain personal library songs through MusicKit on tvOS? Are there additional playback parameters, library synchronization requirements, or recommended queue configurations that could explain why some MusicLibraryRequest() items fail while others work? Has anyone encountered a similar issue or found a workaround that preserves playback of the user’s actual library items? Any guidance would be greatly appreciated. Thank you!

A small number of our users can’t connect Apple Music because DefaultMusicTokenProvider.userToken(for:options:) always throws MusicTokenRequestError.unknown. Most users connect without problems and we can’t reproduce the failure on any of our own accounts. Flow: let status = await MusicAuthorization.request() // .authorized let subscription = try await MusicSubscription.current // canPlayCatalogContent == true let provider = DefaultMusicTokenProvider() let developerToken = try await provider.developerToken(options: []) // succeeds let userToken = try await provider.userToken(for: developerToken, options: []) // throws .unknown On failure we retry once with options: .ignoreCache for both the developer token and the user token. The retry fails in the same way. What we see on affected devices: MusicAuthorization.currentStatus == .authorized MusicSubscription.current.canPlayCatalogContent == true The developer token is returned successfully. userToken(for:) throws MusicTokenRequestError.unknown. The NSError has code 0 and the localized description “Unknown error”, and there is no NSUnderlyingError. The ignoreCache retry fails after anywhere from about 10 ms to 2.5 s, so it sometimes appears to go out to the network. For a given account it fails every time: across days, app versions, and after reinstalling both our app and the Music app. Apple Music plays normally in the Music app for these users. Ruled out so far: iOS version: seen on iOS 26.6.1 and 27.2. Device model: seen on iPhone 13 and iPhone 14 Plus. Region: seen in Hungary, Italy, Romania and Japan. Subscription type: one affected user has an individual trial. A family member with her own individual trial on a separate account connects without problems. Family Sharing in general: family plan members connect fine for us. Questions: What conditions cause userToken(for:) to return .unknown instead of a specific case such as .userNotSignedIn, .permissionDenied or .privacyAcknowledgementRequired? Is there a way to get more detail about the cause? Is there a step affected users can take to fix it?

The documentation for AVAudioSession.Mode.measurement says that this mode will "minimize the amount of system-supplied signal processing to input and output signals" https://developer.apple.com/documentation/avfaudio/avaudiosession/mode-swift.struct/measurement Is there any documentation regarding specifically what processing is applied in the .default or .videoRecording modes and how it is different in .measurement mode? If my app adds its own signal processing, is it best practice to always use .measurement mode? What should I use for an app that applies its own signal processing to the audio in a video recording? Is it possible to "minimize system-supplied signal processing" while recording a video?

With a joined PTChannelManager channel and setAccessoryButtonEventsEnabled(true) completing successfully, what supported condition makes a classic Bluetooth headset's AVRCP Play event start PTT transmission instead of routing to a media app? The headset microphone and physical Stop button work. The next physical Start press produces no didBeginTransmittingFrom callback, while an on-screen Start request works again. Tested environment Observed on 3 October 2026: iPhone 13 Pro Max, iOS 26.6.1. Xcode 26.6, macOS 26.5.2. boAt Rockerz 255 Pro+, classic Bluetooth A2DP/HFP. Push to Talk capability, microphone permission, and audio/push-to-talk background modes enabled. Default half-duplex transmission mode and Ready service status retained. Isolation and setup The reproduction uses an independent UIKit controller initialized before the host app runtime. No React Native, Expo audio module, Live Activity, MPRemoteCommandCenter, Now Playing metadata, audio player, transcription, or backend participates. The controller retains its channel manager, leaves a restored channel before joining a fresh channel, and enables accessory button events in didJoinChannel. The revised test configures the audio session at launch, before manager initialization: let session = AVAudioSession.sharedInstance() try session.setCategory(.playAndRecord, mode: .voiceChat, options: [.allowBluetoothHFP]) The relevant join callback is: func channelManager(_ channelManager: PTChannelManager, didJoinChannel channelUUID: UUID, reason: PTChannelJoinReason) { channelManager.setAccessoryButtonEventsEnabled(true, channelUUID: channelUUID) { error in // The test logs successful completion here. } } PTT owns audio activation/deactivation; the diagnostic never calls setActive. In didActivate, it reapplies the same category/mode/options, clears a speaker override, selects an available HFP input, waits for the route to settle, and starts an AVAudioEngine input tap. It verifies HFP input/output and incoming frame counts; samples are discarded. It removes the tap and stops the engine on Stop/deactivation. The full focused sample was already supplied privately to DTS. Its controller was tested on the physical phone through the native-only launch path. The standalone Xcode project packaging passed an unsigned iPhoneOS build, but has not independently been installed on the phone. Reproduction Connect the headset, launch the diagnostic, grant microphone permission, and join a fresh PTT channel. Confirm that enabling accessory events succeeds. Tap on-screen Start, which calls requestBeginTransmitting(channelUUID:). Wait for HFP input/output and incoming audio frames to be verified. Press and release the headset multifunction button. The delegate reports didEndTransmittingFrom with handsfree/headset source (raw 3); PTT deactivates audio and the channel remains joined. Press and release the same headset button again. Expected: PTT begin callback and microphone activation. Observed: no begin callback; Console shows AVRCP Play routed to Music. Tap on-screen Start again: transmission works. Headset Stop works again. Selected evidence The revised launch-configuration test produced this native trace on 3 October (UTC): 04:32:10 launch: native-only; launch audio configuration v2 04:32:10 category=PlayAndRecord; mode=VoiceChat; options=4 04:32:11 fresh channel joined 04:32:11 accessory mapping accepted 04:32:19 app start requested 04:32:19 BEGIN source=2 04:32:20 available inputs=MicrophoneBuiltIn,BluetoothHFP 04:32:20 discard engine running 04:32:21 HEADSET VERIFIED: BluetoothHFP input/output; frames=4096 04:32:22 END source=3 04:32:23 audio deactivated No physical-headset BEGIN appeared in the native event snapshot copied at 04:32:49 UTC. Selected Console observations from the same run, converted from IST to UTC: 04:32:30.529053 AVRCP Play routed to com.apple.Music 04:32:30.535720 Music launch failed: NotFound 04:32:35.852134 the same command timed out after 5.326288 seconds Music had been removed during troubleshooting. Before removal, the user observed Music opening; the supplied timestamped excerpts were captured after removal. Removal explains the launch failure, but does not explain why the joined PTT channel is bypassed. An earlier native-only fresh-channel control also showed Play routing to Music before any app-requested transmission, with no BEGIN or audio activation in the callback trace. That earlier control configured the category in didActivate; it was not a fresh-start test of the revised launch-configuration variant. The revised test above establishes that configuring the category at launch did not fix the post-Stop failure. Questions I reviewed the accessory mapping explanation in https://developer.apple.com/forums/thread/804205 and the launch audio configuration guidance in WWDC22 session 10117. Is a discrete AVRCP Play command from this type of consumer headset supported for PTT Start in this state, or is a different command form required? Does the playback-mode qualifier in that forum guidance require an additional supported setup step? Could the category/route sequence described above bypass accessory mapping despite successful completion? What targeted diagnostic or controlled configuration would distinguish accessory-command compatibility from an iOS routing defect? The observations establish a routing/callback mismatch in this tested configuration; I am not assuming an iOS defect or that the headset is unsupported.

Hello, I need guidance on diagnosing an intermittent audio failure on an iPhone 12 running iOS 26.6.2. My app, Timer Workout Fitness, plays short bundled MP3 voice recordings for countdowns, repetition numbers and workout announcements. It uses React Native / Expo SDK 57 and expo-audio. The native playback implementation uses AVQueuePlayer, AVPlayerItem and AVURLAsset. Users can listen to Spotify while the app plays spoken cues, with ducking of the background music. Observed behavior: Playback can work correctly for an entire workout. Audio sometimes fails after background/foreground transitions, pausing Spotify, or completing one workout and starting another. The exact sequence is not consistently reproducible. The app may remain navigable while recorded audio becomes unavailable. Force-quitting does not always restore reliable playback. Restarting the iPhone has restored it in our tests. Speech-based voices have generally behaved more reliably before the failure. Evidence from a device Console capture: At 15:03:35 on October 12, the kernel reported termination of audiomxd with reason "per-process-limit" and a recorded footprint of 66866 KB. ReportSystemMemory confirmed the jetsam termination. Shortly before this, the Console contained AudioConverter construction messages associated with our app through mediaplaybackd. Our app subsequently reported media-services loss/reset and errors including: "Server was dead" OSStatus 1836282486 We have not established whether our playback implementation causes an accumulation of native resources, a temporary peak, or another issue. We do not assume that this is an iOS defect. The implementation originally retained up to 56 players for individual recordings and loaded them concurrently. We recently changed it to load only the recordings required by a workout: 15 players for 10 repetitions and 35 for 30 repetitions. Failures have still occurred in development testing, but we have not measured the corresponding native memory footprint. We also have a custom native patch affecting activation/deactivation and handling of media-services loss/reset. Current Expo Go tests do not include that patch; our TestFlight builds do. We can provide the patch for review. What is the recommended way to: Attribute audiomxd memory usage to our app’s playback resources? Verify that AVQueuePlayer items and associated decoding resources are released? Capture useful diagnostics for this service termination? Choose an appropriate playback architecture for frequent short local voice clips alongside background music? We have device Console logs and application diagnostic traces. We do not yet have a minimal native Xcode reproduction project and would appreciate guidance on what it should include.

Hi, I'm working on a project that uses the AVSpeechSynthesizer and AVSpeechUtterance. I discovered by chance that the AVSpeechSynthesizer automatically completes some words instead of just outputting what it's supposed to. These are abbreviations for days of the week or months, but not all of them. I don't want either of them automatically completed, but only the specified text. The completion transcends languages. I have written a short example program for demonstration purposes. import SwiftUI import AVFoundation import Foundation let synthesizer: AVSpeechSynthesizer = AVSpeechSynthesizer() struct ContentView: View { var body: some View { VStack { Button { utter("mon") } label: { Text("mon") } .buttonStyle(.borderedProminent) Button { utter("tue") } label: { Text("tue") } .buttonStyle(.borderedProminent) Button { utter("thu") } label: { Text("thu") } .buttonStyle(.borderedProminent) Button { utter("feb") } label: { Text("feb") } .buttonStyle(.borderedProminent) Button { utter("feb", lang: "de-DE") } label: { Text("feb DE") } .buttonStyle(.borderedProminent) Button { utter("wed") } label: { Text("wed") } .buttonStyle(.borderedProminent) } .padding() } private func utter(_ text: String, lang: String = "en-US") { let utterance = AVSpeechUtterance(string: text) let voice = AVSpeechSynthesisVoice(language: lang) utterance.voice = voice synthesizer.speak(utterance) } } #Preview { ContentView() } Thank you Christian

I am testing an audio-only MediaDeviceExtension on an iPhone 17 Pro, with Xcode 27.0 (27A266a). The same application build reproduces this on iOS 27.0 (24A437), after a full reboot, and on iOS 27.0.1 (24A446). The extension advertises .realtimeAudioStreaming, one stable device UUID and a reachable, nonzero-port endpoint. It connects to the receiver before reporting activatedDevice. From startRealtimeSampleDelivery(session:), it calls AudioServerPlugInRegisterMediaDeviceExtension. The plug-in exposes one output device with the same UID and kAudioDeviceTransportTypeRemoteStreaming. The driver interface lives for the extension process and is registered on each delivery start. Stop/deactivation closes the transport and stops forwarding samples; it does not terminate the extension or register a null interface. Reproduction: start audio, select the extension's route, confirm audio flows, switch to iPhone Speaker, then reselect the same route while the source keeps playing. First selection works; subsequent selections briefly deliver audio before reverting to Speaker with AVOutputContextDeviceConnectionFailureReasonMDERouteRevertedToLocal. Pausing the source before route selection, waiting five seconds and resuming worked repeatedly in the same extension process; uninterrupted reconnection is the required behavior. The normal test uses Spotify and a separate receiving app. A diagnostic control on iOS 27.0 also reproduces first-success/reconnect-failure using a native AVAudioPlayer PCM source and a separate Mac receiver that counts/discards the samples. That control has no Spotify, DSP processing, local receiver playback session or same-phone transport endpoint. Stored device logs on 27.0.1 show two failed reconnects: Observation Reconnect 1 Reconnect 2 System policy chooses fallback before startRealtimeSampleDelivery 11.103 ms earlier 26.956 ms earlier MusicVAD reported present after fallback decision 364.019 ms later 409.215 ms later Driver registration result OSStatus 0 OSStatus 0 New captured frames before system stops delivery 52,224 47,104 Time from fallback decision to Speaker selection 1,507.218 ms 1,507.904 ms The policy logs identify the active, non-video source as not supporting the extension's protocol, then attempt AirPlay fallback. On the first successful connection, MusicVAD is already present and the policy explicitly permits that same source. On reconnect, successful driver publication and subsequent I/O do not cancel the earlier fallback decision. Transport reports show zero drops and socket errors; StartIO/StopIO counts balance, the stream-active setter is honored, and callback session IDs match. No registration interruption is captured during these attempts. Creating a media device extension directs publication from startRealtimeSampleDelivery. The registration API describes the interface, UID and transport requirements, but I have not found the supported teardown/re-registration contract for this retained-process case. Between stopRealtimeSampleDelivery / deactivation and the next delivery start, should the extension retain and re-register the same driver interface, recreate it, or withdraw the audio device through a documented operation? How should an audio-only extension using the documented publication callback ensure the system's compatibility check waits for its audio device? Is there a supported readiness or completion signal that the implementation must provide? The evidence identifies an ordering difference; I am not assuming it proves an OS defect. Guidance on the required lifecycle, or a reference implementation demonstrating uninterrupted reconnects, would help isolate the remaining driver-versus-system boundary.

Our music player plays library and Apple Music catalog content with MusicKit's ApplicationMusicPlayer. On the Mac, we want a volume slider that changes only our app's playback level, like the slider in Music.app. We found no supported way to do this: ApplicationMusicPlayer and MusicPlayer have no volume property. The audio plays in com.apple.MediaPlayer.RemotePlayerService, not in our process, so we cannot change the stream level. MPVolumeView and the deprecated MPMusicPlayerController.volume control the system output volume, not the app's level. AVPlayer cannot play Apple Music catalog content. Questions: Is there a supported API to set the playback volume of ApplicationMusicPlayer on macOS or Mac Catalyst? If there is none, what does Apple recommend for Mac apps that need an app-level volume control for MusicKit playback?