· Title: AudioOutputUnitStart Error 35 (EAGAIN) on macOS Tahoe — RAATServer Build 1501 — Chord Qutest USB
System: • Roon Core: ROCK on Intel NUC, RoonServer v2.62 build 1641 • Endpoint: Mac mini M4, macOS Tahoe 26.3.1, RAATServer v2.60 build 1501, Roon Bridge v2.60 build 1501 • DAC: Chord Qutest, USB connection, Exclusive Mode + Integer Mode enabled
Behaviour: Playback fails with the track stuck at 0:00. The Qutest does not initialise. Restarting ROCK resolves it every time. Occurs regularly but not on every attempt.
Two confirmed triggers: 1. First playback after a long idle period 2. Sample rate switching during an active session (e.g. 44.1kHz → 96kHz between tracks)
Error from RAATServer logs: Warn: [RAAT::Qutest] Error in AudioOutputUnitStart: 35 (0x23) Warn: [RAAT::Qutest] setup failed: RAAT__OUTPUT_PLUGIN_STATUS_DEVICE_INIT_FAILED
Error 35 = EAGAIN — CoreAudio reports the audio output unit as temporarily unavailable. USB enumeration completes correctly and all sample rates are listed. The failure occurs only at the AudioOutputUnitStart call, not during device initialisation.
Log files available.
Notes: This issue persists on current production build 1641. An earlier build 1584 (November 2025) was noted as containing a Tahoe fix, but the identical EAGAIN error continues on the current build. The fix in 1584 either addressed a different variant or was not carried forward to RAATServer. I have not found another report with log evidence of this specific error on Tahoe.
The Roon Community account from which you’re writing isn’t tied to any active Roon account. Do you have a second email address tied to an active Roon account?
A very similar issue—where endpoints would fail to reconnect after waking from standby—was specifically addressed and fixed in our recent 2.61 release.
Looking at your system diagnostics, we can see that your devices have already successfully updated to this version. Could you please confirm if you are still experiencing this exact same connection issue?
If the problem does persist, we definitely want to take a closer look. Please reproduce the issue one more time and reply here with the exact local time the connection fails.
Once you provide that timestamp, we will pull a fresh set of diagnostic logs from your server to see exactly what is going wrong under the hood!
I have a few points of clarification that I hope will help:
Firstly, I’d like to correct something from my original post. I suggested one trigger was first playback after a long idle period, but on reflection this may have been misleading — the failure on 03/07 simply happened to be the first play of the day rather than being demonstrably caused by idle time. I apologise for the misdiagnosis. The only well evidenced trigger is sample rate switching during an active session.
Secondly, regarding the 2.61 fix — my system is already beyond that version. My diagnostics show RoonServer v2.62 build 1641 and RAATServer v2.60 build 1501, so unfortunately the 2.61 fix has not resolved the issue. The identical EAGAIN error at AudioOutputUnitStart is still occurring on these builds.
The good news is that I already have exact timestamps from my existing RAATServer logs where the failures are documented, so hopefully there’s no need to wait for it to happen again:
RAATServer_log.01.txt — failure at 03/07 15:41:10 local time
RAATServer_log.04.txt — failure at 03/03 17:49:07 local time (sample rate switch)
RAATServer_log.05.txt — failure at 03/03 16:24:19 local time (sample rate switch)
I have the full log files ready to share if they would be helpful. Could you please advise the best way to get them to you? I couldn’t see an option to attach files to this post.
Many thanks, I’m really looking forward to getting Roon working properly again.
We have requested the diagnostic report from your environment and it will avaliable for the further review.
Before we dive deepere in the diagnostic, would you kindly give it a try and set the resync delay for the zone with the dropouts during the sample rate switch? More information can be found here :
After this pleae report back and let us know if the issue still persists
Thank you for pulling the diagnostic report and for the suggestion.
I’ve tried the Resync Delay setting at various durations and unfortunately it made no difference — the issue persists. This is consistent with my understanding of the problem: the failure occurs at AudioOutputUnitStart with Error 35 (EAGAIN), which suggests CoreAudio is reporting the audio output unit as temporarily unavailable rather than there being a timing or synchronisation issue that a resync delay would address.
I hope the diagnostic report proves useful. Please do let me know if you need anything further from my end, including the RAATServer log files I mentioned previously.
Thanks for the reply! It looks like your Chord Qutest is having a handshake disagreement with your Mac’s CoreAudio system. The clue we can see from the diagnostic report is:
Essentially, Roon sent a request to “take control” of the DAC at 96kHz/32-bit, and the operating system (CoreAudio) blocked it or the device failed to respond within the expected window.
A few next steps to try:
Power Cycle the Qutest: Chord DACs can sometimes get "stuck" in a specific sample rate state. Unplug the USB and power from the Qutest, wait 30 seconds, and plug it back in.
Check "Audio MIDI Setup" (on Mac):
Open Audio MIDI Setup (cmd + space, type it in).
Find the Qutest in the list.
Ensure no other app is using it as the "Default Output" (the speaker icon). If it is, change the System Output to your Mac Speakers instead.
Toggle "Max Bits per Sample": *
In Roon, go to Settings > Audio.
Find the Qutest and click the "Gears" icon for Device Setup.
Try setting "Max Bits per Sample (PCM)" to 24 instead of 32. While the Qutest handles 32-bit, the CoreAudio handshake is sometimes more stable at 24-bit.
We’ll be monitoring for your reply and response. Thank you!
Thank you for the suggestions. I’ve worked through all of them carefully but unfortunately the issue persists and I have some additional observations to share.
**Steps taken:**
- Resync Delay: tried at various durations — no difference
- Power cycled the Qutest, restarted the Mac mini running Roon Bridge, and restarted ROCK — no change
- Max Bits Per Sample: changed from 32 to 24-bit as suggested — issue persists
- Audio MIDI Setup: Sound Effects and Default Output are both assigned to the Mac mini’s built-in speakers. The Qutest has no system audio assignments and is completely free from any competing audio claims
**New failure — 13/03/26 at 14:01:**
Playback failed when switching from a 24/44.1kHz track to a 24/96kHz track. The timeline stuck at 0:00. After approximately 5 seconds Roon advanced to the next track on the same 24/96 album and failed on that too, continuing to climb through the queue with each track failing after a few seconds. Clearing the queue and attempting to play the same album again did not resolve the issue. Returning to the 24/44.1kHz album that had been playing successfully also failed — at this point nothing would play in Roon at all.
After the Roon failure I tried Qobuz Connect. It didn’t work immediately but after a short wait it played faultlessly without any reboots, settings changes or other interventions.
Following Qobuz playing correctly I tried Roon again at 14:17 — it failed immediately with the timeline stuck at 0:00 again. Only rebooting ROCK again restored Roon playback.
For additional context, the same DAC on the same USB port on the same Mac switches sample rates without any issues when using LMS with Squeezelite, which also operates in exclusive mode.
**A question on the bit depth change:**
Could you confirm that changing Max Bits Per Sample from 32 to 24 has no effect on the precision of MUSE’s internal processing for my DSP settings?
These failures are so regular that Roon is rendered unusable in its current state.
Thanks for the detailed follow-up! I’m sorry to hear none of the above has helped.
To put your mind at ease: No, changing “Max Bits Per Sample” to 24-bit does not affect MUSE’s internal processing precision.
The Error 35 (EAGAIN) indicates that Roon is asking macOS to start the audio engine, but macOS is replying, “I’m busy, try again later,” and then never becomes “un-busy.”
Since you’ve already tried the standard MIDI and bit-depth fixes, let’s look at the “Exclusive Mode” handshake:
Toggle "Integer Mode"
While the Qutest supports Integer Mode, it bypasses part of the macOS sound stack. If there is a bug in the Tahoe CoreAudio implementation, Integer Mode can cause the driver to hang during sample rate transitions.
Test: Disable Integer Mode in Roon’s Device Setup but keep Exclusive Mode enabled. See if the sample rate switching (44.1 → 96) still triggers the hang.
I’d be curious - if you open Activity Monitor on the Mac mini and force quit, RAATServer does that fix it? If this fixes it: The issue is local to the Mac's RAAT implementation.
The EAGAIN error on idle suggests the Qutest is entering a low-power state or the USB bus is suspending.
Go to System Settings > Battery (or Energy Saver) on the Mac mini.
Ensure "Prevent automatic sleeping when the display is off" is ON.
Ensure "Wake for network access" is ON.
A few additional tests for you:
Test with "Force Max Volume": Sometimes EAGAIN is triggered by a volume control handshake failure. Set Volume Limits to "Fixed" in Roon just to rule it out.
Verify USB Path: Are you using any USB hubs? If so, plug the Qutest directly into one of the Mac mini M4’s rear ports. The M4 has a new controller architecture that might be more sensitive to hub timing.
Thank you for the continued support. I’ve now worked through everything on your list and have some additional findings to share.
Steps completed:
Resync Delay: tested at 0, 500, 1000, 1500 and 2000ms — no difference at any setting
Integer Mode: disabled and tested — issue persists identically with Integer Mode both on and off
Force quit RAATServer via Activity Monitor: does not restore playback
Restarting Roon Bridge application: does restore playback without any need to restart ROCK
Force Max Volume: already active in all sessions per the RAATServer logs
USB connection: the Qutest is connected directly to the Mac mini’s rear ports — no hub in the system
Energy settings: Low Power Mode off, Prevent automatic sleeping on, Wake for network access on — all correctly configured
Today’s failures — 18/03/26:
I experienced multiple failures today which may be useful given the volume of log data they generate. The failure times were:
13:49
13:52 / 13:53 (cluster of failures)
14:06
14:11 (Integer Mode off)
14:19 (Integer Mode off)
14:21 (Integer Mode off)
The relevant log files covering these failures are RAATServer_log.01.txt through RAATServer_log.09.txt from today’s session. I have all of these ready to share if you can advise the best way to send them.
Could I ask what today’s testing confirms from your perspective, and how close are we to identifying a resolution? This thread has now been running for over ten days and Roon is currently unusable for me in its present state. I remain keen to get it resolved and am happy to provide whatever further information would be helpful.
Thank you for your patience and continued assistance.
While awaiting your response to my post above, I wanted to share an additional observation that may be relevant to diagnosis.
I notice that RoonBridge — and specifically RAATServer — is an Intel binary running under Rosetta 2 translation on my M4 Mac mini, while the Roon Remote application is native Apple Silicon. Given that the failure occurs precisely at the point where RAATServer interfaces with CoreAudio’s exclusive mode AudioUnit stack, I wondered whether the Rosetta 2 translation layer could be a contributing factor in how this interaction behaves on Apple Silicon under macOS Tahoe.
I appreciate that M-series Macs running Roon Bridge must be a common configuration, so this may not be the sole explanation. However the combination of an Intel binary, Apple Silicon hardware, and macOS Tahoe’s CoreAudio implementation feels worth flagging in case it’s relevant to your engineers’ investigation.
Is a native Apple Silicon build of RAATServer planned, and could this class of issue be related to the architectural mismatch?
I’d also like to ask whether the full Roon application — which is native Apple Silicon — could replace Roon Bridge on the Mac mini and function as an output only endpoint to my existing ROCK core. If so, would this represent a stable and fully supported configuration, and are there any drawbacks I should be aware of compared to running Roon Bridge?
I’m happy to provide any further information that would help.
Thanks for the exact timestamps! We successfully pulled your diagnostic logs from our end, and our engineering team is reviewing them now.
Your theory regarding the Rosetta 2 translation layer is excellent. Bypassing it by using the full, native Apple Silicon Roon application as a dedicated endpoint is a fantastic test idea. It is a fully supported configuration with no real drawbacks on an M4 Mac.
To test this:
Completely quit Roon Bridge on your Mac mini.
Install the standard Roon app and choose to Connect to your existing ROCK Core.
Enable your DAC in Settings > Audio.
Please let this native setup run for a day or two. If playback stabilizes, it will give our team a massive clue! We look forward to your results.
Thanks for the reply. I have uninstalled Bridge and installed the full version of Roon. I will test this over the next few days as suggested.
Please let me know the outcome of your engineering team’s review.
I will come back to you once I’ve tested the full app as a Bridge replacement.
Looking through Roon’s past releases, it appears the issue I’ve been experiencing was fixed in the full version of Roon in Dec ’25. It also appears this fix has not filtered through to the current version of Bridge. Can you confirm this is the case please?
Full Version of Roon:
Roon v2.57, Build 2.57 (Dec ’25) changes include: “Fixed an issue on macOS Tahoe where playback to local audio devices could fail to initialize after changing the sample rate.”
Roon Bridge (last two releases – I think?)
Bridge v2.60, Build 1501 (Feb ’26): out-of-cycle security release (no other changes?)
Bridge v1.8, Build 1125 (Sept ’22): Minor adjustment in preparation for Roon 2.0 release
Your engineer’s diagnostic conclusion and confirmation on whether the Tahoe fix is missing from Bridge would be greatly appreciated.
Thanks for installing the full, native Apple Silicon Roon application to test as your endpoint. Let us know how it performs over the next few days.
To answer your question regarding the macOS Tahoe fix from December: both the full Roon application and Roon Bridge share the exact same RAAT (Roon Advanced Audio Transport) architecture. Core transport fixes apply to both, so the patch wasn’t simply omitted from the Bridge build.
That being said, your theory regarding the Rosetta 2 translation layer is a very interesting variable. We have passed your exact timestamps, log files, and this specific Rosetta 2 theory over to our Quality Assurance (QA) team. They are going to use this data to try and replicate the CoreAudio handshake failure on their test benches. If QA can reproduce the exact issue in that environment, they will escalate it to our R&D team for further investigation.
Please report back on how the native Roon app performs during your testing. Your results will be very helpful for our QA team’s efforts!
Thank you for suggesting I test the full Roon application as a replacement for Roon Bridge. I’ve now completed an initial test session and wanted to share my results.
Due to having blocked ears at the moment I wasn’t able to do a normal representative listening session, so instead I cycled through a large number of tracks from different albums in quick succession, playing approximately ten seconds of each before moving on. This was deliberately designed to generate as many sample rate switches as possible in a short period.
The good news is that the session felt completely stable throughout. I was able to move through the queue freely without any lockups, without needing to restart anything, and without the characteristic failure I’d been experiencing where tracks would stick at 0:00 and Roon would become unusable. This is a significant improvement over what I’d been experiencing with Roon Bridge.
I did encounter a small number of tracks that failed to play. The details are below:
14:59 — Asking to Break, James Blake — failed to play, moved on
15:09 — White Dress, Lana Del Rey — failed to play, moved on
15:12 — Hold You Now, Vampire Weekend — failed to play, moved on
15:31 — Asking to Break, James Blake — tried again, failed again
15:33 — White Dress, Lana Del Rey — tried again, failed again
15:34 — Hold You Now, Vampire Weekend — tried again, played fine this time
In all cases I was able to simply move on without any lockup or need to restart, which is very different from the behaviour I was experiencing before. The session continued normally after each failure.
Are you able to shed any light on why these three tracks failed? I’m happy to provide logs if that would help your investigation.
I also wanted to follow up on your previous note that both the full Roon application and Roon Bridge share the same RAAT architecture and that transport fixes apply to both. I’ve been looking through the release notes and I can see that the fix for macOS Tahoe playback initialisation after sample rate changes is referenced in the full application release notes — I believe it was first included in build 1584. I’ve been unable to find a corresponding entry in the Roon Bridge release notes. I may well have missed something, so could you confirm whether that specific fix was included in a Bridge release and if so which build it appeared in? I ask only because the RAATServer version within the full Roon application appears to be build 1641, whereas Roon Bridge was running RAATServer build 1501, and I want to make sure I have a complete understanding of what has changed.
I’d also be grateful to hear what your engineering team has concluded from examining my previous RAATServer logs.
I’ll continue testing over the coming days and will report back if I experience any further issues.
Just a quick note to keep this thread active whilst awaiting your response. I’m continuing to test the full Roon application as suggested and will report back with further findings shortly.
We’re very grateful for your patience in the meantime as we looked into diagnostics.
For future reference, if you’re a Roon dealer, you can always email the dedicated dealer support channel directly at dealersupport@roonlabs.com
First off, the track names you’ve listed appear to all be sourced from Qobuz around that timestamp in logs. Is that correct?
In each case, the stoppage event was consistent with a now-resolved Qobuz API issue. Here’s the tracking thread. The content delivery network upon which the Qobuz API relied for some hi-res tracks was failing to properly deliver data.
As you transitioned to “White Dress” from the previously queued track, Roon registered a strong connection speed for the connection to Akamai; nonetheless, the prebuffer never received any data and the track arrested at 0:00 until the server reestablished the connection to Qobuz.
Theoretically, this symptom would have reproduced on any endpoint. Qobuz has since resolved the issue.