Overview: macOS Music AirPlay “cold start” to HomePod stereo pair intermittently fails (status -128, null picked route), while switching to HomePods during active playback succeeds.
Setting: MacBookPro M3 14" (2023), macOS Tahoe 26.2 (one admin account, one standard account, firewall on, IPv6 automatic), HomePods second generation (MQJ73AX/A, 2 × stereo pairs, four in total in the same room, close to the Wi-Fi router), HomePodOS 26.2, Orbi RBR850 firmware v4.6.9.11. (Note: This has been a recurring issue since macOS 12.0.1 Monterey (26/10/2021), on a MacBook Pro Intel 13" 2017, HomePods first generation (MQHW2X) in 2 × stereo pairs), HomePodOS 15.1, Time Capsule (A1470) and AirPort Extreme (A1521), both firmware 7.9.1. Once the problem started it was never resolved, only briefly, and might have contributed to the constant overheating, and subsequent failure, of the four original HomePods.)
Description: Based on data captured from 'live unified log stream' and 'unified log database' across eight test runs (Sunday 21/12/2025), this is what ChatGPT (5.2, Thinking, Efficient) and Claude (Opus 4.5) were able to establish:
- macOS Music.app intermittently fails to establish an AirPlay audio route to a HomePod stereo pair when the route is selected while playback is stopped and playback is subsequently initiated ("cold start").
- In failing runs, logs show BufferedAirPlayAddOutputDeviceToContext() returning status -128, followed by "aborted connection due to error -128," and mediaremoted reporting ApplicationPickedRoutes message with route descriptions: (null).
- In successful runs, the logs instead show the confirmation "audio device:Pods_* … connected," followed by log activity consistent with an established output route.
- Across the observed runs, routing succeeds when playback is already active on local speakers before switching output to the HomePods, and also succeeds when playback begins immediately after selecting the HomePods. Routing fails in the observed cases where the HomePods are selected while playback is stopped, an idle interval elapses, and playback is then initiated.
- The logs contain endpoint group membership changes (groupID transitions and groupContainsDiscoverableGroupLeader toggling) in both successful and failing runs, so these cannot be identified as the cause from this data alone.
- A plausible hypothesis is that transient endpoint-group state changes widen a race window during cold-start route setup, increasing the likelihood of the -128 failure. The precise semantics of -128 in this context and the internal code paths differentiating the success and failure scenarios are not established by these logs.
This does not happen, and could not be reproduced on playback from an iPhone (iOS 26.2) to the HomePods. Again, according to ChatGPT and Claude: "It likely does not happen from iOS because iOS uses a different AirPlay session-management path than macOS Music “cold start” routing. On iPhone, the audio session and route selection tend to be driven by a tightly integrated, always-on media stack that keeps route negotiation and playback state changes in one coordinated state machine, so selecting a HomePod pair and starting playback is less exposed to a race between “route chosen” and “playback state transition.” On macOS, the logs show that the failure is coupled to Music’s paused-to-playing transition while attaching an AirPlay output context, which suggests a macOS Music-specific timing window that iOS either does not have or handles with retries and stabilization before committing the route."
