Frequent dropouts with TIDAL 24/192 on Mac mini (ref#BNY190)

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

· Roon Server Machine
Mac mini (Apple silicon, 10 cores), macOS 26.6.2, Roon Server 2.x
Library: ~8,050 tracks

Networking Gear & Setup Details
UniFi router, Wi-Fi 6E (6GHz, 160MHz). Comcast, ~360 Mbps measured
during the failures. No VPN, no proxy, no exit node.

Connected Audio Devices
Astell&Kern HC5 USB DAC connected directly to the Roon Server machine
(CoreAudio, exclusive mode). This is the endpoint used for every test
below, so no network hop is involved between server and endpoint.

Description of Issue
24/192 TIDAL content stops mid-track with "Track Stopped Due to Slow
Media". Roon reports insufficient throughput from TIDAL, but the same
machine pulls the same track from the same TIDAL CDN host at 10-15x
that rate when the native TIDAL app does the fetching.

Roon, playing 24/192 TIDAL to the AK HC5:
19:39:42 poor connection kbps:5547.0 (min:5953.0)
19:40:02 poor connection kbps:4580.0 (min:5953.0)
19:40:22 poor connection kbps:4561.0 (min:5953.0)
[prebuffer] sleeping in read -- this isn't good (174 occurrences)
19:46:31 Too many dropouts. Killing stream
19:46:31 Track Stopped Due to Slow Media
Last failing track: "Two Hands Of A Prayer" - Ben Harper & The
Innocent Criminals, killed at 1:03 of 7:54, 27 Aug 2026 19:46:31 PDT.

Native TIDAL desktop app, SAME machine, SAME AK HC5 in exclusive mode,
SAME track, CoreaudioSink rate 192000 int24, minutes later. Fetching
from lgf.audio.tidal.com, 10 MiB segments:
10.0 MiB in 1199ms = 76.2 Mbps
10.0 MiB in 1551ms = 55.9 Mbps
10.0 MiB in 1673ms = 52.4 Mbps
10.0 MiB in 2356ms = 36.4 Mbps
10.0 MiB in 1302ms = 64.5 Mbps
underruns/stalls: 0

Controlled comparison, all to the same endpoint within one hour:
TIDAL 44.1/16 via Roon clean, 0 dropouts
Local 192kHz FLAC via Roon clean, 0 dropouts
TIDAL 24/192 via Roon starved at ~4.5 Mbps, stream killed
TIDAL 24/192 native app 36-76 Mbps, flawless

The local 192kHz file is a higher bitrate than the TIDAL stream that
fails, and it plays perfectly through Roon to the same DAC. That rules
out the DAC, the USB path, CPU, and local bandwidth.

Ruled out with measurements
- CPU: RoonAppliance peaked at 34.9% of one core (10-core machine)
during the failure; average ~7%.
- WAN: 362 Mbps measured concurrently with the starvation.
- Network hop: the AK HC5 is attached to the server machine itself,
so no RAAT network hop is involved in this failure.
- CDN/ISP: native app pulled 76 Mbps from the same lgf.audio.tidal.com
host over the same connection.
- DNS: issue predates my current DNS setup by years.

Additional detail that may be relevant
Roon's own logs show short requests achieving full speed while long
ones do not, on the same host and token:
ti/57C6D0F2 blocks read: 7 download speed: 34133kbps
ti/9F87079A blocks read: 987 download speed: 4497kbps
ti/BB7BC6A8 blocks read: 2034 download speed: 4695kbps
The native app fetches in discrete 10 MiB range requests and sustains
36-76 Mbps. This looks like it may be specific to how Roon's fetch
maintains a long-lived connection.

I have also seen this same symptom on Qobuz in past years, on
different networks, which is why I do not believe this is
service-specific or ISP-specific.

Tell us about your home network

· Roon Server Machine
Mac mini (Apple silicon, 10 cores), macOS 26.6.2, Roon Server 2.x
Library: ~8,050 tracks

Networking Gear & Setup Details
UniFi router, Wi-Fi 6E (6GHz, 160MHz). Comcast, ~360 Mbps measured
during the failures. No VPN, no proxy, no exit node.

Connected Audio Devices
Astell&Kern HC5 USB DAC connected directly to the Roon Server machine
(CoreAudio, exclusive mode). This is the endpoint used for every test
below, so no network hop is involved between server and endpoint.

2

Hi @Sascha_Trinkaus,

Thanks for the detail, the measurements are solid and they let me get somewhere. Your logs do show the effect you describe: across five days, 148 sustained fetches, Roon never exceeded 4,846 kbps, while 24/192 needs 5,769–6,595 kbps (Roon’s own set min bandwidth figures). That’s why those tracks die 40–70 seconds in, with the endpoint at 2% buffer.

But I don’t think the ceiling is Roon’s doing, and there are three things in the logs worth checking before we go further.

1. The Mac mini appears to be on Wi-Fi, not Ethernet. Roon enumerates interfaces at startup, and en0 has no IPv4 address, the only one it finds is on en1. On a Mac mini that’s the Wi-Fi adapter, with the Ethernet port unused. Can you confirm? Your testing ruled out WAN throughput, but throughput and packet loss are different quantities, and it’s loss that matters here.

2. There’s a VPN-class tunnel active. Roon finds utun8 at 100.105.241.xx and binds services to it. That’s a Tailscale or WARP-style interface, it’s up even if you’re not routing through an exit node.

3. Latency to the CDN is high. Median time-to-first-byte to lgf.audio.tidal.com is 167 ms, with a p90 of 325 ms. A nearby edge should be 10–30 ms. It’s not TIDAL-specific either: api.roonlabs.net has a p99 of 2.8 seconds in your logs.

What to try, in order:

  1. Connect the Mac mini by Ethernet and replay a failing 24/192 track. Single biggest lever, 6 GHz at 160 MHz has short range and is sensitive to interference, and Wi-Fi retries show up as exactly this kind of loss.
  2. Quit the VPN client entirely (not just the exit node) and retest.
  3. Measure loss instead of speed. During a failing track, from Terminal: sudo ping -i 0.2 -c 900 <your router IP>, and netstat -s -p tcp | grep -i retrans immediately before and after. Anything above ~0.01% loss, or a meaningful jump in retransmits, is your answer.
  4. Turn off Threat Management (IPS/IDS) and any Smart Queues or QoS in UniFi for one test. Those inspect long-lived flows and leave short ones alone, which is the exact asymmetry you’re seeing.

Send me the ping and netstat output plus fresh logs after the Ethernet test and we’ll know quickly. Thank you!

3

Hi Benjamin,

Thanks — that was a genuinely useful reply, and you caught an error in
my original ticket. I ran all four of your tests. One correction to
concede, three results, and a statistic I think isolates this.

FIRST, YOU WERE RIGHT AND I OVERCLAIMED
I said local 192kHz playback rules out local bandwidth. It doesn’t. My
library is on the mini’s internal disk and an attached USB drive with
no network mounts, so local playback never touches the network at all.
It rules out the DAC, the USB path and CPU. It says nothing about the
network. That inference was wrong and I’ve dropped it.

  1. ETHERNET — CONFIRMED, TESTED, STILL FAILS
    You were right that en0 was unused. I moved the mini to wired Ethernet
    (via a powerline adapter — no long cable to hand). en0 active at
    1000baseT full-duplex, en1 down, default route via en0, Roon Server
    restarted afterwards so it rebound.

The link improved substantially:
Wi-Fi Ethernet
LAN latency 12.0ms avg, sd 21ms 3.0ms avg, sd 1.1ms
CDN latency 26.7ms avg, sd 23.5ms 15.4ms avg, sd 2.8ms
Single-flow bursty 120-152 Mbps sustained
Packet loss 0% 0%

Roon failed identically anyway:

14:26:47 Too many dropouts. Killing stream
14:27:28 Too many dropouts. Killing stream
poor connection kbps:4410.0 (min:6419.0)

  1. VPN — RULED OUT ON TIMELINE
    utun8 is Tailscale, installed 2026-08-19. I have hit this exact problem
    for years before that, including on Qobuz in a different apartment, in
    a different country, on a different ISP. It cannot be the cause.

  2. LOSS AND RETRANSMITS — MEASURED, ESSENTIALLY ZERO
    500 packets to lgf.audio.tidal.com 0.0% loss
    200 packets to api.roonlabs.net 0.0% loss
    600 packets to gateway + AP 0.0% loss
    netstat -s -p tcp retransmit delta across a sustained transfer: 0

For TCP to be pinned at ~4.5 Mbps at my 15-27ms RTT, the Mathis relation needs roughly 1% loss. I’m not seeing a fraction of that. I
agree loss matters more than throughput — it just isn’t present.

  1. IPS AND SMART QUEUES — TESTED, NOT THE CAUSE
    This was the most promising idea, and I wanted it to be right, because
    I also ran UniFi during the Qobuz era. Intrusion Prevention was on
    (Notify and Block, 32,908 signatures). I disabled it entirely and the
    failure was unchanged. Smart Queues has never been enabled — off by
    default on my UCG-Max. Failures recur identically with IPS on or off.

THE STATISTIC I THINK MATTERS
Every completed fetch from your logs today, grouped by size:

<=10 blocks n=4 median 22,036 kbps max 42,666

100 blocks n=27 median 3,339 kbps max 4,654

Sustained fetches exceeding 5,769 kbps (24/192 minimum): 0 of 27

Short requests are ~6.6x faster than long ones on the same connection,
to the same host, with the same token, often seconds apart. That holds
across Wi-Fi and wired Ethernet, and with IPS on and off.

THE CONTROL THAT BOTHERS ME MOST
The TIDAL desktop app on this same machine, playing the same 24/192
track to the same Astell&Kern HC5 in exclusive mode, fetching from the
same lgf.audio.tidal.com, using 10 MiB range requests:

10.0 MiB in 1199ms = 76.2 Mbps
10.0 MiB in 1551ms = 55.9 Mbps
10.0 MiB in 2356ms = 36.4 Mbps
underruns: 0

Same host, same machine, same DAC, minutes apart. The native client
gets 36-76 Mbps in discrete chunks. Roon gets under 4.7 sustained.

WHAT I’VE ELIMINATED

Tidal/CDN        native app pulls 76 Mbps from the same host
Wi-Fi            wired test above, identical failure
Jitter           8x reduction, identical failure
Packet loss      0% across 1,300+ packets
IPS/IDS          disabled, identical failure
Smart Queues     never enabled
CPU              RoonAppliance peak 34.9% of one core, 10 cores
Prefetch         single track, empty queue, still starved
VPN              predates install by years
DAC/USB          local 192kHz flawless to the same DAC

One note on the Ethernet test: it runs over a powerline adapter rather
than a direct cable run. Before you ask me to redo it, I measured the
link specifically for the failure mode in question — sustained
single-flow transfers:

100 MB single flow, Hetzner 154 Mbps sustained
100 MB single flow, OVH 77 Mbps sustained
Gigabit full-duplex negotiated, 0% loss over 600 packets
LAN jitter 1.1ms stddev (Wi-Fi was 21ms)

A single sustained flow holds 154 Mbps — roughly 24x the 6.4 Mbps that
24/192 requires, on exactly the transfer shape that fails in Roon. The
link is not the constraint. I can arrange a direct run if you still
want it, but I’d suggest the evidence doesn’t depend on it.

I’m out of environmental variables. Short Roon requests hit full line rate
on every transport I’ve tried; sustained ones collapse to the same
3-4.7 Mbps band regardless of medium, jitter, loss, gateway
configuration or concurrency. What in Roon’s fetch path differs
between a 2-block request and a 700-block one?

Thanks,
Sascha

4

Can cause issues on it’s own and is why Roon in it’s networking FAQ recommend to use direct Ethernet if a powerline install is still having issues.

5

Hi @benjamin,

Three more results since my last message. All of your remaining
suggestions are now tested.

  1. DIRECT ETHERNET — NOT POWERLINE, NOT WI-FI
    It was raised in the thread that a powerline adapter can cause issues
    on its own, so I removed it. The mini is now cabled directly into the
    gateway. Link measured immediately before testing:

Single sustained flow 274 Mbps
RTT to gateway 0.7 ms avg, 0.064 ms stddev
RTT to ``lgf.audio.tidal.com`` 12.2 ms avg, 2.1 ms stddev
Packet loss 0.0%

Result, single 24/192 track, nothing queued: four “Track Stopped Due
to Slow Media” kills in under four minutes.

09:42:22 / 09:43:09 / 09:43:49 kills
poor connection kbps:4231.0 (min:6742.0)
blocks read: 2 download speed: 32,000 kbps
blocks read: 677 download speed: 4,372 kbps

  1. VPN — FULLY REMOVED, NOT JUST THE EXIT NODE
    Tailscale quit entirely, the VPN configuration disabled in System
    Settings, and iCloud Private Relay switched off (wasn’t ever on). utun8 no longer
    existed during the test. Same direct-Ethernet connection:

10:08:47 / 10:09:37 / 10:10:14 Track Stopped Due to Slow Media
poor connection kbps:4674.0 (min:6731.0)
blocks read: 2 download speed: 18,285-30,117 kbps
blocks read: 868 download speed: 4,490 kbps

Identical failure with zero tunnels on the machine.

  1. THE PATTERN, NOW ACROSS EVERY CONFIGURATION
    The same fingerprint has reproduced on:

Wi-Fi 6E fails
Powerline Ethernet fails
Direct gigabit Ethernet to gateway fails
With and without Tailscale/VPN fails
IPS on and off, Smart Queues off fails

In every case: requests of a few blocks reach 18-42 Mbps, sustained
requests collapse to 4.4-4.7, and 24/192 starves. Across all logged
fetches to date, no sustained request has ever exceeded the 24/192
minimum — 0 of 27 on the day I counted.

The native TIDAL app control still stands: 36-76 Mbps from the same
CDN host, same machine, same DAC, zero underruns.

I attempted an iPhone-hotspot test to rule the ISP path in or out, but
my phone carrier wouldn’t cooperate. Given the fetch asymmetry is
identical across three transports and appears in the first seconds of
every stream, I don’t believe the ISP path is the variable — but I’m
open to running any test you’d design for that.

At this point every environmental factor you and the thread have
raised is tested and eliminated. The one constant is Roon’s sustained
fetch. My question stands: what differs in Roon’s fetch path between a
2-block request and a 700-block one? I suspect whatever governs that
is the answer.

Fresh logs from both tests available.

Thanks,
Sascha

6

Hello @Sascha_Trinkaus

Thank you for the update.

Regarding the CDN: while both Roon and the TIDAL app hit lgf.audio.tidal.com, that is only the entry node. Inside Akamai’s infrastructure, third-party API integrations like Roon are routed to entirely different content nodes or traffic tiers than native apps, which can explain the stark difference in sustained speeds.

Before I pass your fetch block data to our developers, I need one final test to completely isolate the hardware feedback loop.

Please physically disconnect the Astell&Kern HC5 DAC. Enable your Mac’s default “System Output” in Roon’s Settings > Audio and play the exact same 24/192 track.

Let me know how the System Output handles the stream.

7

Hi Vadim,

Ran the System Output test. Astell&Kern HC5 physically disconnected.
Zone is “Mac Mini” (built-in / System Output). Same 24/192 TIDAL
material.

Signal path: 24/192
TIDAL FLAC => 24/96
(built-in output won’t lock 192; Roon still fetches the 192 stream —
set min bandwidth 6238 kbps)

Result, minutes ago:

17:09:41 Track Stopped Due to Slow Media
17:10:06 Track Stopped Due to Slow Media
17:10:31 Track Stopped Due to Slow Media
17:11:03 Track Stopped Due to Slow Media

poor connection kbps:3366.0 (min:6238.0)
blocks read: 1 download speed: 25,600 kbps
blocks read: 491 download speed: 3,877 kbps

Same short-fast / long-slow fingerprint, no USB DAC in the chain.

Happy for you to pass the fetch-block data on.

Sascha

8

Hey @Sascha_Trinkaus,

Thank you for the testing, the short-fast/long-slow measurements and the System Output control test are what made the fresh logs readable. We’ve been through them (Aug 29 – Sep 2), and they point somewhere different from where this thread has been looking.

Across 179 sustained fetches over four days and all three of your network configurations, not one exceeded 4,582 kbps, while short fetches on those same connections hit 21,000–36,500 kbps. What that describes is a flow carrying a fixed amount of data in flight, around 64 KB, where throughput is set by round-trip time alone. Sustained rate × measured latency lands within 59–78 KB on every one of the four days. Throughput moves only because latency moves, which is why wired Ethernet, IPS off and removing the powerline adapter changed nothing: none of them shortened the round trip. (It was also never 24/192-only, two 24/96 tracks needing ~3.5 Mbps starved at 2,713 and 2,740 kbps.)

It also isn’t TIDAL. We wanted to test the CDN-tiering theory properly, and the logs allow it:

DestinationOperatorSamplesFastestMedianimagecache.roonlabs.netRoon180 (<20 KB)90 ms196 msapi.roonlabs.netRoon8,28971 ms198 msapi.tidal.comTIDAL1,15365 ms185 mslgf.audio.tidal.comTIDAL / Akamai23261 ms172 ms

TIDAL has no influence over how fast Roon’s own image CDN answers, so a TIDAL-side traffic tier can’t explain this. Four services, two operators, two CDNs, one latency profile, and the only thing they share is your Mac mini and the network in front of it. A residential Comcast line should reach any of them inside 15–40 ms.

One caveat first. Those are HTTP response times, not pings, if Roon Server opens a fresh TLS connection per request, each figure covers three or four round trips and your real RTT could be a healthy 20–25 ms. So please start here, on the Mac mini with nothing playing:

for h in imagecache.roonlabs.net api.tidal.com lgf.audio.tidal.com; do
  echo "== $h"; ping -c 10 -q "$h" 2>/dev/null | tail -2
done

If that comes back above 100 ms, the latency is real and there are three things to check, in order:

  1. DNS steering. Uniform latency to four unrelated CDNs is the classic signature, a resolver that strips EDNS Client Subnet hands Akamai and Fastly the resolver’s location instead of yours. Tailscale MagicDNS, NextDNS, DoH profiles, iCloud Private Relay and UniFi DNS Shield all do this. Run scutil --dns | head -40 and dig +short lgf.audio.tidal.com, then force the same lookup at your ISP’s resolver and compare the edge IP.
  2. Tailscale, once more. You’ve ruled it out as a routing cause and we agree. DNS steering is a separate mechanism, and Roon Server is still binding 100.105.241.19. Quit the client outright, not just the exit node, and re-run the two tests above.
  3. The gateway. Disabling Intrusion Prevention turned off signature matching, not the inspection path; DPI, Smart Queues and traffic identification are separate toggles. Faster than working down that tree: tether the Mac to your phone’s hotspot and play one 24/192 track. Clean playback on cellular points at the gateway.

If the RTT comes back at 20–30 ms instead, the window behaviour is ours to account for and we’ll pick it up from there. Either result moves this forward.

9

Hi @benjamin,

Ran the idle ping on my Mac mini (nothing playing, default route en0):

imagecache.roonlabs.net`` min/avg/max 12.4 / 16.8 / 23.5 ms 0% loss
api.tidal.com`` 11.2 / 15.2 / 20.6 ms 0% loss
lgf.audio.tidal.com`` 11.0 / 35.7 / 81.1 ms 0% loss
api.roonlabs.net`` 35.0 / 51.0 / 88.5 ms 0% loss

That is the 20–30 ms side of your fork, not >100 ms.

Then the hotspot test, then the same tracks straight back onto Ethernet.

Hotspot (today 16:18–16:57 PDT)
iPhone personal hotspot, Ethernet unplugged (en0 inactive).
WAN: T-Mobile 172.56.170.29 (Sacramento).
Tidal Max, 24/192. First Mac Mini 192→96, then Astell&Kern HC5 exclusive 32/192.
Slow Media / Too many dropouts: 0
Long fetches typically 5.7–6.8 Mbps; several cleared the min
(6798, 6688, 6395 kbps).
ICMP on this path was worse than home (lgf avg 57 ms, api.tidal 130 ms).

Ethernet, same machine / same HC5 / same Max queue (17:02–17:14)
en0 → UniFi, Wi-Fi off.
17:05:50 Too many dropouts / Track Stopped Due to Slow Media
(Oh! You Pretty Things), fetches 4960 then 5043 kbps
later long fetches 3771, 5626, 3781, 832 kbps vs min ~6624

Same Roon, same DAC, same 24/192 files. Native TIDAL on this Comcast path
still does 36–76 Mbps. Home pipe is ~1400 Mbps; we already measured 274 Mbps
sustained on this Ethernet connection and 0% loss.

So: ICMP says the window behavior is yours. The long GET is also
path-sensitive. On T-Mobile it clears ~6 Mbps and plays. On Comcast/UniFi
it sits ~3.3–5.0 and dies. That is not “not enough bandwidth.”

Caveat on the four-day extract: after 31 Aug I left Tidal in Roon on High (44.1) except when running a Max test, because I need to listen. High cannot produce 24/96 or 24/192, those starve lines are Max. The 179-fetch mix includes High listening days. Today’s two runs were Max throughout.

Thank you for the window analysis. I will keep Tidal on High
here so I can listen. I need the fetch path fixed: short requests fly,
long ones die under 24/192, and ping to those hosts is 15–35 ms on
Ethernet. Please take that to whoever owns the downloader.

Best,
Sascha

10

Hello @Sascha_Trinkaus

We’ve discussed this with our senior QA and development teams. The team is investigating some possibilities here and, as soon as that investigation is complete, we’ll be sure to follow up ASAP.

You have our apologies for the trouble here, and we’ve greatly appreciated your patience as we continue investigating this tricky issue. We’ll be in touch as soon as we can.

11

Fantastic. Thanks @vadim. Appreciate you and the team looking into this. Let me know how I can help.

12

Hello @Sascha_Trinkaus,

Thanks for the detailed testing and for working through this with us.

The investigation is underway, and as soon as that work is complete, we’ll follow up with you.

We’ll keep an eye on it from here, and if we need anything else, we’ll let you know.