Local output not working on MacOS 27 with ROCK, endpoints functioning (ref#6U1WJY)

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

· Running MacOS 27 and ROCK, local (computer) output doesn't work (both speakers and USB DAC) are clearly broken: they don’t show up, other than a quite ugly blinking bug in settings / audio that might be trying to show something and makes me think there might be some type of permission issue there. Endpoints work.

Tell us about your home network

· Not a network problem (see above).

Here’s Settings => Audio. The glitching is faster on-screen, but since i can’t upload a video file, here it is as a gif.

screen_recording

2

Hello @Xekomi

Your network endpoints work and only the Mac’s own outputs are missing. That points at the macOS 27 local network permission, which we are seeing on a lot of Macs right now.

On a Mac, the local outputs are published by RAATServer, and your ROCK has to reach it over the network. macOS gates that behind a permission called Local Network access, and a macOS update can leave Roon without it.

Please work through this article on the Mac:

Start with “Check Roon’s Local Network Permission”, then “If Roon Isn’t Listed Under Local Network”. If the outputs are still missing after a restart, use the “macOS 27: Try the Network Workaround” section further down.

3

Hi @vadim , thanks for taking the time to pick up on this. Since it seemed obvious, I forgot to mention, I’d gone through the steps prior.

Now, onto more useful stuff, here’s what I’ve traced down.

After the speaker is discovered and the JSON server starts, RAATServer repeatedly logs

[jsonserver] uv_tcp_nodelay failed: invalid argument
[jsonserver] uv_tcp_getpeername failed: invalid argument

These errors repeat every few seconds.

I also reproduced the exact same errors using a completely local connection:

nc 127.0.0.1 9200

The log showed:

[jsonserver] [127.0.0.1:49305] accepted connection
[jsonserver] uv_tcp_nodelay failed: invalid argument
[jsonserver] uv_tcp_getpeername failed: invalid argument
[jsonserver] [127.0.0.1:49305] read error: connection reset by peer

This, to me, signals the errors are not dependent on the ROCK or LAN connection, hence my “not a network problem”.

Now, RAATServer logs also contain macOS security error -25294. Stack traces show it occurring around SecKeychainItemCopyKeychain. The login keychain exists, is the default keychain, and unlocks successfully. RAATServer itself has valid Roon Developer ID signing. I did not reset/delete the keychain.

From what I understand, RAATServer advertises itself successfully:

[servicemanager] added device raatserver/<UUID>
[servicemanager] added service com.roonlabs.raatserver.tcp
[servicemanager] registered 1 devices, 1 services

As far as I can tell, CoreAudio sees the MacBook Pro Speakers, RAATServer discovers them, RAATServer starts and listens, ROCK can reach RAATServer, but RAATServer’s JSON/socket handling starts returning EINVAL (uv_tcp_nodelay / uv_tcp_getpeername) even for a localhost client, and the Mac audio endpoint never becomes available in Roon.

This is about as far as I’d been able to get before I asked. Please let me know if there’s something further you’d like me to look into on my end.

4

Hi @Xekomi,

Our diagnostic servers haven’t been able to complete an upload request for Roon logs from the affected Mac. At your convenience, can you please open Roon on that machine and reproduce this issue? This should provide enough of a window for the pending upload to complete and capture the event.

Since you’ve looked through RAATServer logs, are those specific logs on the Mac abruptly ending in any of the 20 listed entries? The screen capture you shared looks more like a RAATServer crash; and logs from the ROCK show the Mac’s RAATServer instance jumping up and down on the network. This could, of course, be one of the many symptoms that the Golden Gate network security can cause with RAAT.

The team will soon release stabilizing work for Roon targeting these issues on macOS 27. In the meantime, we’ll take a closer look at logs in this case and determine a next step.

Thank you!

5

Hi @connor, thanks for taking the time to look into this… unfortunately, it seems like the hotfix doesn’t address the core of the issue that’s causing whatever’s going on here.

27_3_1

6

Did you renew the network permissions? It helped others. (The longstanding network permission renewal issue as such is not expected to be fixed (yet?))

  1. Open the Apple menu and select System Settings.
  2. Click Privacy & Security in the sidebar.
  3. Click Local Network.
  4. Check whether Roon and Roon Server are both listed and turned on.
  5. If they’re already on, turn each one off, then back on.
  6. Restart your Mac.
  7. Open Roon and check Settings > Audio again to see if your devices appear.

System Settings Privacy and Security Local Network panel showing Roon and Roon Server toggles

7

Did you renew the network permissions?

Yes.

8

:sob:

(10chars)

9

Hi @Xekomi,

Thanks for your patience.

The ROCK server logs show the Mac interwork interface (not Roon or RoonServer) closing down the TCP connection before RAAT and Roon can send and receive traffic.

This isn’t the standard macOS 27.0 network restriction, which has been resolved both by the Roon 2.73.1 hotfix and also by the macOS 27.0.1 subsequent Golden Gate update.

The usual culprit for this symptom is third-party software that filters network traffic, like a firewall, VPN, or security app. To check, could you please:

  1. Zip up the RAATServer logs from the Mac and send them over. These will be in the Roon folder of the /Library on the Mac remote. Here’s a guide for accessing logs. Upload the zip here.
  2. Run systemextensionsctl list in Terminal and paste the output here, or at least describe any VPNs you use on the Mac.
  3. Boot into Safe Mode on the Mac, run nc 127.0.0.1 9200 again, and let us know if the errors still show up in Roon. Safe Mode turns off third-party extensions, so if the errors stop there, we’ll know where to look.

As a side note, RAATServer continues to retry on the dead socket with no backoff; this isn’t the cause of your issue but it’s exacerbating the symtom. The team has a ticket in the pipeline to address that.

We’ll watch for your reply.

10

Hi @Xekomi,

If you’re able to continue troubleshooting at this time, we’d be able to take the process to the next step as soon as we receive the above information from you.

If you need more guidance on how to perform the steps, please, let us know.

If you’d rather come back at a later time, considering this request will automatically close in a few days without a reply, you can always reopen it here:

(None of the above quite fits → Reopen a previous technical support request)