macOS 27 regression: HDMI + DisplayPort Multi-Output audio fails with Core Audio error 1937010544

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:

  1. The physical device is detected normally.
  2. The audio format is configured successfully.
  3. Core Audio reports that StartIO succeeded.
  4. The device subsequently reports that it is not running.
  5. Core Audio waits 10 seconds for a timeline.
  6. Timeline establishment fails.
  7. 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:

  1. Boot macOS 27 with both MSI MP243X monitors connected.

  2. Open Audio MIDI Setup.

  3. Verify both MSI MP243X devices work independently.

  4. Set both devices to 48,000 Hz.

  5. Create a new Multi-Output Device.

  6. Select both MSI MP243X devices.

  7. Select the new Multi-Output Device as the system audio output.

  8. 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.

did you use Feedback Assistant to file a bug? This isn't a bug reporting forum.

Same regression here on macOS 27.0.1 (26A434), with two DisplayPort displays, so it isn't specific to HDMI + DP:

  • MacBook Pro 16" 2021 (M1 Pro)
  • 2 × Dell S2725QC, each on its own USB-C port (DP Alt Mode, no dock)

Each display's audio works alone, never both at once. The display whose link was negotiated last (boot, replug, refresh-rate change) gets audio; the other fails with the same 'stop' (1937010544) / "could not establish a timeline" error, so a Multi-Output Device with both never starts.

It happens below Core Audio: when one display's DP audio DMA starts, the other's stops (its DCPAVAudioDMADelegate TransferInformation counters in the IORegistry freeze, and the kernel logs DCPAVAudioDriver … stopIOEngineGated: _hostTime=0). Different sample rates per display, renegotiating both links at once, restarting coreaudiod and rebooting don't help.

Partial workaround: changing a display's refresh rate (e.g. 120 → 60 → 120 Hz) gives that display the audio back, at the expense of the other.

Filed as FB25041393.

+1. User-initiated, AI-assisted report: at my request, Codex checked local logs and browser state on my M1 Max MacBook Pro, macOS 27.0.1 (26A434). I personally confirmed that built-in speakers restored playback. Chrome and Safari could not play YouTube with HDMI audio, even after a restart. Chrome had 18 seconds buffered but stayed at 0. Logs showed timeline establishment timeout, error 1937010544, and DCPAVAudioDriver stopIOEngineGated: _hostTime=0. Failures affected EP-HDMI-RX and Dell U5226KW endpoints. This resembles FB25041393, but the identical Multi-Output trigger and root cause are unproven. Is Apple investigating?

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
  1. 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.
  2. 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.

I have same issue here on macOS 27.0.1 (26A434).

  • MacBook Pro 14" (2021), M1 Pro (MacBookPro18,3)
  • Displays:
    • Philips 27E1N2600A via HDMI audio works
    • Philips 27E1N5900 via USB-C (DP Alt Mode) audio fails
    • I also tried another USB-C display, and it fails the same way.
  • Symptom: Playing to the USB-C display hangs for about 10 seconds and then fails. No samples are ever output. Built-in speakers and the HDMI display work normally. 100% reproducible.
  • Log (matches the original report):
    HALS_IOContext_Legacy_Impl::IsTimeRunning_Helper: Device ... 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
    

+1 for a fix.