Post

Replies

Boosts

Views

Activity

Reply to macOS 27 regression: HDMI + DisplayPort Multi-Output audio fails with Core Audio error 1937010544
I have the same problem with multi-output on 27.0.1. I had my LLM burn through a bunch of tokens to diagnose and report the issues. I hope this helps provide some insights: The root cause behind the audio failures between your two LG monitors on macOS 27.0.1 comes down to three interconnected issues: 1. Apple Silicon Display Co-Processor (DCP) Timeline Limitation By inspecting ioreg and the live coreaudiod server logs, we discovered that: Both monitors are managed by DCPAVAudioDriver within Apple's Display Co-Processor (Apple M3 Max). Both display endpoints report the exact same hardware clock domain (1835100526 / 'mcln'). In macOS 27.0.1, the DCP driver only exposes one active hardware audio timeline/clock engine at a time across external display outputs (the native HDMI port and the USB-C DisplayPort Alt-Mode link). When macOS attempts to start audio on both display links simultaneously (via an Aggregate or Multi-Output Device in Audio MIDI Setup), CoreAudio's HALS_IOContext_Legacy_Impl attempts to anchor a second timeline on the shared clock. The DCP hardware link fails to advance sample frames for the second monitor, logs: coreaudiod: HALS_IOContext_Legacy_Impl::IOWorkLoop: could not establish a timeline after waiting 10000000 microseconds ... Device is not running. coreaudiod: IOWorkLoopDeinit: stopping with error 1937010544 ('stop')After a 10-second timeout, it kills the second link with error 1937010544 ('stop', FourCC for kAudioHardwareNotRunningError). Empirical proof conducted on your machine: When Monitor A is started first, Monitor A plays cleanly and Monitor B fails with 'stop'. When Monitor B is started first, Monitor B plays cleanly and Monitor A fails with 'stop'. Pairing MacBook Pro Speakers + Monitor A or Speakers + Monitor B in a Multi-Output device succeeds immediately (because built-in speakers run on an independent clock domain, AppleAudioServerDriverTransports). 2. The Boot Race & Swapping UIDs (Why it's not the same monitor every boot) Both of your LG HDR 4K displays share the exact same EDID manufacturer code (GSM), product code (0x4F77), and a null serial number (00000000). Because the serial numbers are identical, macOS generates the identical base UID: 1E6D4F77-0000-0000-0B1F-010380462878. Whichever monitor finishes link-training first at boot claims the base UID. The second monitor gets assigned a synthesized suffix (e.g. _00000010 or _00000020). Handshake speeds between native HDMI 2.1 and the USB-C dock's DisplayPort-to-HDMI bridge vary at power-on. Whichever monitor wins the race claims the primary slot, causing the "failing" monitor to swap unpredictably across reboots. Furthermore, any Multi-Output device saved in Audio MIDI Setup references fixed UIDs; when the UIDs swap at reboot, the stored Multi-Output profile points to dead or shifted endpoints. 3. The 24-bit vs. 16-bit Default Mismatch In /Library/Preferences/Audio/com.apple.audio.DeviceSettings.plist, the base UID had saved preferences for 16-bit 48.0 kHz. Whenever a monitor was assigned a new dynamic UID (like _00000010), it defaulted to 24-bit 48.0 kHz (as reported by the monitor's EDID CTA-861 block). Over the USB-C adapter (constrained to 2 DP lanes at 30Hz), the 24-bit LPCM stream was unable to clock at all, failing even solo playback until we coerced it to 16-bit 48.0 kHz. Immediate Fix & Workarounds How to unwedge a monitor without rebooting: Toggling the nominal sample rate (44.1 kHz -> 48.0 kHz) forces CoreAudio to tear down and re-initialize the DCP audio engine. Both monitors have now been reset to 16-bit 48.0 kHz and verified working individually. Dual-Audio Workaround: Because DCP cannot clock two display-audio streams simultaneously, simultaneous dual audio can be achieved by routing audio through: 1x LG Monitor via HDMI + 1x USB Audio Device (notice your hub already provides a USB PnP Audio Device with a 3.5mm jack). Because USB audio uses AppleUSBAudioEngine on an independent clock domain, a Multi-Output Device with HDMI + USB Audio works reliably. 1x LG Monitor + MacBook Pro Speakers. Let me know if you would like me to build a permanent script/daemon to automate UID tracking, unwedge stalled display endpoints on wake/boot, or set up a hybrid Multi-Output configuration.
Topic: Media Technologies SubTopic: Audio Tags:
1w
Reply to macOS 27 regression: HDMI + DisplayPort Multi-Output audio fails with Core Audio error 1937010544
I have the same problem with multi-output on 27.0.1. I had my LLM burn through a bunch of tokens to diagnose and report the issues. I hope this helps provide some insights: The root cause behind the audio failures between your two LG monitors on macOS 27.0.1 comes down to three interconnected issues: 1. Apple Silicon Display Co-Processor (DCP) Timeline Limitation By inspecting ioreg and the live coreaudiod server logs, we discovered that: Both monitors are managed by DCPAVAudioDriver within Apple's Display Co-Processor (Apple M3 Max). Both display endpoints report the exact same hardware clock domain (1835100526 / 'mcln'). In macOS 27.0.1, the DCP driver only exposes one active hardware audio timeline/clock engine at a time across external display outputs (the native HDMI port and the USB-C DisplayPort Alt-Mode link). When macOS attempts to start audio on both display links simultaneously (via an Aggregate or Multi-Output Device in Audio MIDI Setup), CoreAudio's HALS_IOContext_Legacy_Impl attempts to anchor a second timeline on the shared clock. The DCP hardware link fails to advance sample frames for the second monitor, logs: coreaudiod: HALS_IOContext_Legacy_Impl::IOWorkLoop: could not establish a timeline after waiting 10000000 microseconds ... Device is not running. coreaudiod: IOWorkLoopDeinit: stopping with error 1937010544 ('stop')After a 10-second timeout, it kills the second link with error 1937010544 ('stop', FourCC for kAudioHardwareNotRunningError). Empirical proof conducted on your machine: When Monitor A is started first, Monitor A plays cleanly and Monitor B fails with 'stop'. When Monitor B is started first, Monitor B plays cleanly and Monitor A fails with 'stop'. Pairing MacBook Pro Speakers + Monitor A or Speakers + Monitor B in a Multi-Output device succeeds immediately (because built-in speakers run on an independent clock domain, AppleAudioServerDriverTransports). 2. The Boot Race & Swapping UIDs (Why it's not the same monitor every boot) Both of your LG HDR 4K displays share the exact same EDID manufacturer code (GSM), product code (0x4F77), and a null serial number (00000000). Because the serial numbers are identical, macOS generates the identical base UID: 1E6D4F77-0000-0000-0B1F-010380462878. Whichever monitor finishes link-training first at boot claims the base UID. The second monitor gets assigned a synthesized suffix (e.g. _00000010 or _00000020). Handshake speeds between native HDMI 2.1 and the USB-C dock's DisplayPort-to-HDMI bridge vary at power-on. Whichever monitor wins the race claims the primary slot, causing the "failing" monitor to swap unpredictably across reboots. Furthermore, any Multi-Output device saved in Audio MIDI Setup references fixed UIDs; when the UIDs swap at reboot, the stored Multi-Output profile points to dead or shifted endpoints. 3. The 24-bit vs. 16-bit Default Mismatch In /Library/Preferences/Audio/com.apple.audio.DeviceSettings.plist, the base UID had saved preferences for 16-bit 48.0 kHz. Whenever a monitor was assigned a new dynamic UID (like _00000010), it defaulted to 24-bit 48.0 kHz (as reported by the monitor's EDID CTA-861 block). Over the USB-C adapter (constrained to 2 DP lanes at 30Hz), the 24-bit LPCM stream was unable to clock at all, failing even solo playback until we coerced it to 16-bit 48.0 kHz. Immediate Fix & Workarounds How to unwedge a monitor without rebooting: Toggling the nominal sample rate (44.1 kHz -> 48.0 kHz) forces CoreAudio to tear down and re-initialize the DCP audio engine. Both monitors have now been reset to 16-bit 48.0 kHz and verified working individually. Dual-Audio Workaround: Because DCP cannot clock two display-audio streams simultaneously, simultaneous dual audio can be achieved by routing audio through: 1x LG Monitor via HDMI + 1x USB Audio Device (notice your hub already provides a USB PnP Audio Device with a 3.5mm jack). Because USB audio uses AppleUSBAudioEngine on an independent clock domain, a Multi-Output Device with HDMI + USB Audio works reliably. 1x LG Monitor + MacBook Pro Speakers. Let me know if you would like me to build a permanent script/daemon to automate UID tracking, unwedge stalled display endpoints on wake/boot, or set up a hybrid Multi-Output configuration.
Topic: Media Technologies SubTopic: Audio Tags:
Replies
Boosts
Views
Activity
1w