Roon Remote on MacBook Pro M3 shows Core's audio devices instead of local devices (ref#UTOBJG)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Hello,

I'm experiencing a very unusual issue with Roon on two Macs.

System

Core

MacBook Pro Early 2015
macOS Monterey
Running Roon Server only

Remote

MacBook Pro M3
Latest macOS
Fresh installation of Roon (Remote only)

Both machines are on the same local network.

Background

Initially, both Macs had Roon Server installed at different times.

I accidentally connected the M3 to a small, incomplete database.

After that I restored my correct database on the 2015 Mac.

The library, DSP settings, TIDAL, radio stations and all other data are now fully restored and everything works correctly.

The only remaining issue is audio device discovery on the Remote.

The problem

On the M3 Remote, under Settings → Audio, I see exactly the same "This Mac" devices as on the Core.

For example:

nd8006 (USB DAC connected physically to the 2015 Core)
built-in output
System Output
Microsoft Teams Audio

The entire Audio page is identical on both Macs.

When I enable built-in output on the M3 and play music, the sound comes from the 2015 Mac's internal speakers, not from the M3 speakers.

It appears that the Remote is displaying and controlling the Core's CoreAudio devices instead of exposing its own local CoreAudio devices.

What I have already tried
Completely removed and reinstalled Roon on the M3.
Deleted all local Roon and RAATServer folders.
Verified that the M3 is connected only as a Remote.
Verified that the 2015 is the only active Core.
Restarted both machines multiple times.
Verified that macOS correctly detects the M3 audio devices.
RAATServer

RAATServer on the M3 successfully detects the local hardware.

system_profiler SPAudioDataType reports:

MacBook Pro Speakers
MacBook Pro Microphone
BlackHole
Microsoft Teams Audio

The RAATServer log shows successful registration:

FOUND id=BuiltInSpeakerDevice
registered 1 devices, 1 services
POST https://discovery.roonlabs.net/1/register
status code: 200

There are no errors in the RAATServer log.

Despite that, no separate local playback zone ever appears for the M3.

Expected behavior

I expected the M3 Remote to expose its own local playback device (MacBook Pro Speakers / Built-in Output) as a separate audio zone, while the Core would continue exposing its own local devices independently.

Instead, both computers show identical local CoreAudio devices, and selecting "built-in output" always plays through the Core's speakers.

Has anyone seen this behavior before?

Is there a way to force the Core to rediscover or recreate the Remote's local CoreAudio endpoint?

Any help would be greatly appreciated.

Thank you.

Tell us about your home network

· no vpn, router ubee

2

Hey @srdjan_djurdjevic, welcome to the community, this does sound unusual.

What you are describing points to the Mac Roon Remote on the M3 still acting as if it is tied to the other Roon Server, rather than exposing its own local audio system. A couple of things would help us confirm that and decide the next step:

  • When the M3 opens Roon, does it clearly show the 2015 Mac as the selected Roon Server in Settings?
  • On the M3, are both machines on the same Apple ID and are you using any screen sharing, audio routing, or remote desktop tools on either Mac?
  • Did you use Time Machine or any other third party software to restore a backup from one Mac to the other?
Since you have already cleared the local Roon and RAATServer data on the M3, the next useful check is to fully sign out of Roon on the M3, quit Roon and RAATServer, then reboot the M3 and launch Roon again. If the audio page still mirrors the other Mac after that, we will want to look at the diagnostics around the time you open Settings > Audio on the M3, so please note the exact local time when you test it next and send that back here.

If you can also share a screenshot of the M3 Audio page, that would help us compare what Roon is seeing on each machine.

3

Hi,

Screenshot 2026-07-28 at 13.15.15
Screenshot 2026-07-28 at 13.15.152704×1477 296 KB

Thank you for your reply.

Here are the answers to your questions, along with the additional troubleshooting I have already performed.

  1. Selected Roon Server

Yes. The M3 is definitely connected to the 2015 Mac, which is the only active Roon Server. The M3 is running only Roon Remote.

  1. Apple ID / Screen Sharing

Both Macs are signed into the same Apple ID.

However:

  • I am not using Screen Sharing.

  • I am not using Remote Desktop.

  • I am not using any audio routing software between the two Macs.

  1. Migration / Restore

I did not use Time Machine or any third-party migration software.

The only restore I performed was restoring my Roon database from a Roon backup after accidentally connecting to a different, incomplete database.

The database is now fully restored and everything else works correctly (DSP, TIDAL, radio stations, settings, etc.).

  1. Signing out / Reinstalling

Since opening this topic I have already tried all of the following:

  • Logged out of my Roon account on the M3.

  • Rebooted the M3.

  • Deleted the local Roon and RAATServer folders.

  • Reinstalled Roon completely.

  • Verified that only the 2015 Mac is running Roon Server.

  • Verified that the M3 runs only Roon Remote.

Unfortunately, the behavior is exactly the same.

  1. Additional diagnostics

I also checked the following:

  • Both Macs have different Bonjour names and different hostnames.

  • Local Network permission is enabled for Roon on the M3.

  • macOS correctly detects the local speakers on the M3.

  • RAATServer on the M3 also detects the local speakers correctly.

For example, the RAATServer log shows:

  • BuiltInSpeakerDevice detected

  • Device successfully registered

  • Registration with discovery.roonlabs.net returns HTTP 200

So the M3 appears to register successfully as an endpoint.

  1. The remaining problem

The only issue is that the M3 never exposes its own local audio device as a separate playback zone.

Instead, under Settings → Audio, the M3 shows exactly the same “This Mac” devices as the Core.

For example, it shows my ND8006 USB DAC, even though the DAC is physically connected only to the 2015 Mac.

If I enable Built-in Output on the M3 and play music, the sound comes from the 2015 Mac’s internal speakers, not from the M3 speakers.

The Audio page on both Macs is effectively identical.

This makes it appear that the Remote is displaying and controlling the Core’s CoreAudio devices instead of exposing its own local CoreAudio devices.

I have attached a screenshot of the Audio page on the M3.

If you would like, I can also provide the RAATServer logs or any additional diagnostic information.

Thank you very much for your help.

4

Hey @srdjan_djurdjevic,

Thanks for all the additional information! I believe we understand the underlying issue here, and I will follow-up via private message for next steps in troubleshooting, as it contains sensitive information.

Head into your Community profile messages and I’ll share those next troubleshooting steps. :folded_hands:

6

Thank you, the problem I wrote about is now solved, local outputs on M3 are now active, but after following the reset procedure, I now have a different issue. The Core starts, but RoonServer repeatedly loses its connection to the local RAATServer:

lost client connection

client connection failed

client connection failed. Giving up

At the same time:

  • iPhone stays on “Waiting for your Roon Server”

  • Remote on M3 only connects manually

  • Local playback on M3 is unstable

  • ND8006 playback also stopped working.

It looks like RoonServer can no longer communicate with its own local RAATServer.

7

Hello @

Since you’re running macOS, please try the following steps to check permissions:

  1. Open macOS System Settings → Privacy & Security → Local Network
  2. Make sure Roon and Roon Server are both enabled
  3. Even if they are already enabled, please toggle them off and back on
  4. Fully quit Roon Server from the macOS menu bar / task bar
  5. Reboot your Mac
  6. After reboot, launch Roon again and check if the devices is avaliable again.

Once these permissions are refreshed and the system restarted, your audio devices should reappear.

Please let us know if the issue persists after these steps, and we’ll continue from there.

8

Hi,

I followed the reset procedure exactly as instructed.

Here is what I did:

  • Created a fresh Roon database backup.

  • Closed Roon on both Macs.

  • Deleted the .rmembid file on both the 2015 Mac (Core) and the M3 Mac (Remote).

  • Deleted the RAATServer folder on both machines.

  • Deleted the Roon folder on the M3 Remote.

  • Reinstalled Roon on the M3.

  • Started the Core on the 2015 Mac first, then connected the M3 as a Remote.

This solved the original issue: the M3 now correctly exposes its own local speakers instead of mirroring the Core’s audio devices.

However, a new problem appeared.

Current symptoms:

  • The M3 can only connect if I manually choose “Connect to Srdjan’s MacBook Pro”.

  • Playback on the M3 is unstable. Music starts, then pauses, time stops and jumps forward, tracks sometimes skip, etc.

  • The iPhone Roon Remote no longer discovers the Core at all. It only shows “Waiting for your Roon Server”.

  • Even the ND8006 connected directly to the Core stopped playing correctly after the reset procedure.

I also noticed repeated connection failures in the Core logs:



[RaatServer srdjan-macbook-pro @ 192.168.0.32:9200] lost client connection
client connection failed. Retrying...
client connection failed. Giving up

It looks like the Core is repeatedly losing communication with its own local RAATServer.

You also suggested checking:

System Settings → Privacy & Security → Local Network

On my M3 this setting exists and Roon is already allowed.

However, my 2015 Mac does not have a Local Network section in Privacy & Security at all, so I cannot perform that part of the troubleshooting. If that is expected for my macOS version, please let me know.

Could you please advise what to check next? At this point it seems the Core itself is having trouble communicating with its local RAATServer after the reset.

Thank you!

9

Hey @srdjan_djurdjevic,

Great news that the M3 is now exposing its own local outputs, that confirms the reset did its job on the original issue.

The new symptoms are a different animal: this is a network discovery and local-connection problem, not an audio-endpoint one. Two things stand out. First, the iPhone stuck on “Waiting for your Roon Server” plus the M3 needing a manual connection tells us multicast/mDNS discovery is failing on your network, even though direct connections still work. Second, the Server repeatedly losing its own local RAATServer (“lost client connection… giving up”) points to something interrupting that local link.

A few things to check, roughly in order:

  1. Local Network on the 2015 Mac, you can set this one aside. Monterey predates the per-app Local Network toggle, so its absence is expected and not the problem.
  2. Firewall on the 2015 Mac, System Preferences → Security & Privacy → Firewall. If it’s on, either turn it off to test or make sure Roon, Roon Server, and RAATServer are all set to allow incoming connections. A “block all incoming” setting will break RAATServer.
  3. Give the Server a fixed IP, reserve 192.168.0.32 (or assign a static IP) in your Ubee’s DHCP settings, then reboot. A changing lease can cause exactly these repeated connection failures.
  4. Ubee router settings, look for IGMP snooping/proxy and any “client isolation” or “AP isolation” options and disable them. If you’re able, the cleanest test is to temporarily connect the Server, M3, and iPhone through a simple switch or a different router and see if discovery comes back. If it does, the Ubee is the culprit.
  5. BlackHole, I noticed you have the BlackHole virtual audio device installed. Try uninstalling it and re-testing, just to rule it out as interfering with device enumeration.

Once you’ve tried those, could you also grab the full RoonServer and RAATServer logs from the 2015 Mac right after you reproduce the drop, and note the exact local time it happens? The snippet shows the failure but not the cause, and the full logs around that timestamp will tell us a lot.

One last thought for down the road: a 2015 MacBook Pro on Monterey is fairly light for a Roon Server. If the network checks come back clean, moving the Server role over to the M3 would likely give you a much smoother experience.

Talk soon :+1:

10

Hi,

Thank you for the detailed suggestions.

I went through all of them and here are the results:

  • The M3 now correctly exposes its local outputs (“This Mac”), so that original issue is resolved.

  • The 2015 Mac is running macOS Monterey, so there is no Local Network permission to enable.

  • The macOS firewall is disabled (or, if enabled during testing, Roon, RoonServer and RAATServer were allowed).

  • The Server now has a fixed IP address.

  • The M3 was tested directly next to the router to rule out Wi-Fi signal quality.

  • No VPN, Private Relay, Tailscale, Cloudflare WARP, antivirus or third-party firewall software is installed.

  • BlackHole is still installed. Since the problem affects every local output, including the built-in speakers and wired headphones, I wasn’t convinced it was the cause. However, I can uninstall it if you think it’s important to rule it out.

  • Both TCP ports 9330 and 9332 are listening correctly, and the M3 maintains established connections to the Core.

However, the symptoms remain exactly the same.

The important observation is that the problem is not source-specific:

  • local library playback stutters,

  • TIDAL playback stutters,

  • Internet Radio stutters,

and it happens on every local output of the M3:

  • Built-in Speakers,

  • wired headphones,

  • other local outputs.

At the same time:

  • Spotify,

  • YouTube,

  • TIDAL’s own application,

all play perfectly on the M3 with no interruptions.

So the issue appears to be isolated to Roon playback on the M3.

Another observation is that macOS logs repeatedly report:



HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload

at approximately the same time that the audible dropouts occur.

RoonServer logs themselves do not show network errors or streaming interruptions during playback.

One thing I would also like to mention is that I am not convinced the iPhone discovery issue and the M3 playback issue necessarily have the same cause. They started around the same time, but the Core communicates normally with the M3 (ports 9330/9332 are established), while only local playback on the M3 experiences audio dropouts.

Could you please advise what additional diagnostics you would recommend at this point? In particular, are there any known issues with Roon 2.79 (build 1671) on Apple Silicon Macs that could produce this behavior?

I’ve attached the requested RoonServer and RAATServer logs captured immediately after reproducing the problem. The most recent dropout occurred at approximately, 2 August, 22:39:00 (local time). ronn logs from mac 2015 and macbook pro m3

One additional observation: the exact same Core, network and router work perfectly when streaming to my Marantz ND8006. The problem only occurs when the M3 MacBook Pro itself is used as the playback endpoint (“This Mac”).

Thank you.

11

Hey @srdjan_djurdjevic,

Thanks for sending those over! We can now see that alongside the built-in speakers, the M3 is exposing:

  • BlackHole 2ch
  • Microsoft Teams Audio (a virtual driver)
  • a Multi-Output / aggregate device named “black hole + slušalice” (AMS2_StackedOutput), which stacks BlackHole together with your headphones

That aggregate device is the thing I’d focus on. A Multi-Output/aggregate has no single hardware clock to act as master, so Core Audio has to continuously resample and drift-correct between BlackHole’s virtual clock and the headphone clock. That work runs on the same real-time audio cycle RAAT depends on, and when a cycle overruns you get exactly the message you’re seeing, HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload, and an audible gap at that moment.

This fits every symptom you’ve described. It’s Roon-only because Spotify, YouTube and the TIDAL app hand audio to the shared macOS mixer, whereas RAAT runs its own tight low-latency render loop that actually trips on the overload. It’s independent of source (local, TIDAL, Radio) because the fault is downstream at the output stage. It hits wired headphones because the headphones are literally one half of that stacked device. And it never touches the ND8006 because that endpoint is self-clocked over USB and doesn’t rely on the Mac’s Core Audio timing at all.

Two things worth checking together, as they can interact: if the M3 zone in Roon is set to “This Mac / System Output”, that follows the macOS default output, so if the default is ever the BlackHole stack, Roon is feeding the aggregate no matter which output you think you picked. That’s likely why even the built-in speakers are affected.

Could you try this and report back:

  1. In Audio MIDI Setup, delete the “black hole + slušalice” Multi-Output device.
  2. Uninstall BlackHole completely (not just deselect it), then reboot.
  3. In Roon, set the M3 zone to the explicit “MacBook Pro Speakers” device rather than “System Output”, and confirm the macOS default output isn’t the BlackHole stack.
  4. Reproduce your usual playback and see whether the dropouts and the HALC overload messages stop.

If it still stutters after that, please grab a fresh RAATServer log from the M3 captured during a dropout (~/Library/RAATServer/Logs/ on the M3), that will show the render underruns directly and tell us whether anything else is starving the audio thread.

One minor, unrelated housekeeping note: the M3 is on DHCP and its address shifted (192.168.0.28 → 192.168.0.36 in the logs), and .28 is also the Server’s address. If the Server’s fixed IP was set as a static address inside the router’s DHCP range, it’s worth converting that to a proper DHCP reservation to rule out any occasional address overlap. That’s a tidy-up rather than the main issue.

Thank you! :folded_hands:

12

Hi again,

I wanted to provide an update because I believe we are now dealing with two separate issues.

The original issue was the Roon playback stuttering on my M3 MacBook Pro when using it as a Remote. As discussed previously, this only affected Roon (local files, TIDAL and Internet Radio alike), while Spotify, YouTube and the TIDAL app worked perfectly. Following your advice, I investigated the BlackHole/Multi-Output configuration and was in the process of testing those recommendations.

However, before we could finish troubleshooting the original playback issue, a new and much more serious problem appeared after updating to Roon 2.71 (build 1680) and reinstalling Roon on my 2015 MacBook Pro, which is my Roon Server.

The new issue is that I can no longer connect to the Roon Server at all.

Here is the current situation:

  • My 2015 MacBook Pro (macOS Monterey 12.1) is the intended Roon Server.

  • My M3 MacBook Pro is used only as a Remote.

  • After the update/reinstallation, every client (including the M3 and the iPhone) remains on “Find Roon Server” / “Waiting for your Roon Server.”

  • Roon launches normally.

  • RAATServer launches normally.

  • RoonServer never starts.

  • No RoonServer process remains running.

  • Ports 9330 and 9332 are never opened.

I performed a clean reinstall, verified the application installation, removed the macOS quarantine attribute, rebooted the machine, and confirmed that the Roon application bundle is correctly installed in /Applications. None of these steps changed the behavior.

I also collected the crash report from the 2015 Mac. It consistently shows that RoonServer aborts immediately during startup with:

  • EXC_CRASH (SIGABRT)

  • Assertion failed: CGSConnectionByID

  • Stack trace involving AppKit / NSStatusItem

  • Identifier: com.roon.RoonHeadlessManager

Running ps after launching Roon shows only:

  • Roon

  • RAATServer

There is never a running RoonServer process.

At this point I believe we are no longer troubleshooting the original playback issue, because I currently cannot get the Roon Server running at all.

I have attached the RoonServer logs and the crash report. Could you please advise what might be preventing RoonServer from starting after the update to 2.71 (build 1680), or let me know if this is a known issue on macOS Monterey? roon server logs and crash reports

Once the Server is running again, I will be happy to continue troubleshooting the original playback issue on the M3.

Thank you very much for your help.

13

Hello @srdjan_djurdjevic

You are right that these are two separate issues, and the second one has an answer already.

What you are seeing on the 2015 MacBook Pro is a known bug in 2.71 build 1680 that prevented Roon Server from starting on macOS 12 and 13. Macs on macOS 14 and later were not affected. Your crash report matches it exactly, down to the assertion in the headless manager, so there is nothing wrong with your installation and nothing further you need to test.

We released a hotfix yesterday, Roon 2.71 build 1683, which fixes this specifically. Details are here:

Please download it from

and install it on the 2015 MacBook Pro.

Once Roon Server is running again, please confirm the build number under Settings, then About, and we will pick the original stuttering issue on the M3 back up from where we left it.

14

Hi,

I wanted to provide a further update following our previous troubleshooting.

The crash issue on the 2015 MacBook Pro has now been resolved. Roon Server is running normally on the 2015 MacBook Pro, and the phone can connect to it successfully. However, the M3 MacBook Pro still cannot discover or connect to the Roon Server.

We have now been able to isolate the problem further.

The current network configuration is:

  • 2015 MacBook Pro (Roon Server): 192.168.0.29

  • M3 MacBook Pro (Roon client): 192.168.0.28

  • Both machines are on the same local network.

Basic network connectivity is working, although we initially saw intermittent packet loss. Repeated tests subsequently showed stable connectivity between the two Macs.

More importantly, from the M3 we tested the Roon Server’s TCP ports directly:

  • 192.168.0.29:9330 — connection succeeded

  • 192.168.0.29:9332 — connection succeeded

  • 192.168.0.29:9150 — connection succeeded

On the 2015 MacBook Pro, we also confirmed that Roon is actually listening on the relevant ports:

  • RoonAppliance is listening on *:9330

  • RoonAppliance is listening on *:9332

  • Roon Server and RAATServer are running normally.

The macOS application firewall is disabled on the 2015 MacBook Pro, so this does not appear to be a firewall issue.

The most significant finding is with Bonjour/mDNS discovery.

On BOTH Macs, running:

dns-sd -B _roon._tcp local

produces only:

Browsing for _roon._tcp.local
…STARTING…

and absolutely no service is discovered.

For comparison, mDNS itself is definitely working on the network. On the M3, for example:

dns-sd -B _services._dns-sd._udp local

correctly returns numerous services, including:

_airplay
_raop
_heos-audio
_qobuz-connect
_tidalconnect
_spotify-connect
_http
_googlecast
_homekit
etc.

We can also discover the Marantz ND8006 via Bonjour, and AirPlay devices are visible.

So this does NOT appear to be a general Bonjour/mDNS failure on the network.

The important difference is that Roon is not advertising a _roon._tcp service at all.

We also confirmed that RoonAppliance on the 2015 Mac has active mDNS sockets:

lsof -iUDP:5353

shows RoonAppliance with multiple IPv4 UDP 5353 sockets.

We additionally captured mDNS traffic with tcpdump on both Macs. mDNS traffic is clearly present, but the Roon service is still not discoverable as _roon._tcp.

At this point, the situation appears to be:

  1. Roon Server is running normally on the 2015 Mac.

  2. The server is listening on the expected TCP ports.

  3. The M3 can establish direct TCP connections to those ports.

  4. General LAN connectivity works.

  5. macOS firewall is disabled.

  6. Bonjour/mDNS works for other services.

  7. RoonAppliance has mDNS sockets open.

  8. However, Roon does not appear to publish/discover its _roon._tcp service.

  9. The M3 therefore remains stuck at “Find Roon Server”.

This is why I now suspect a Roon discovery/Bonjour issue rather than a general network configuration problem.

One additional detail: the 2015 Mac is running the Roon Server from:

/Volumes/Roon 1/Roon.app/

and the Roon Server process is running normally from that installation.

Could you please advise what you would like us to check next specifically regarding Roon’s mDNS/Bonjour service advertisement and discovery?

At this point I would prefer not to make further network changes or return to the unrelated BlackHole/DSP issue until we establish why Roon is not advertising/discovering _roon._tcp despite the server itself being reachable on all of its TCP ports.

Thanks again for your help.