Dropouts on 192k Qobuz content with Linn players (ref#4MG0WV)

Support
1

What’s happening?

Dropouts on 192k only, on Linn player only

Describe the issue

Dropouts on 192k/24bit content streamed to Linn players using Linn Songcast.

Have narrowed down:

  • <192k is ok
  • All non-Linn players are ok (including 192k to Lumin, iPad etc)
  • Linn player is OK when streaming direct from Qobuz (outside Roon)
  • More than one Linn player is affected
  • Network cabling is sound with no packet loss
  • Running Linn server on Mac gives no dropouts on the Linn player
  • Some sluggishness on Roon control panel, and interactions can trigger dropouts

(More details in following post.)

Therefore I am suspecting ROCK/NUC is overloaded when pushing out Songcast streams? However I don’t know how to diagnose further as ROCK is a closed system.

Describe your network setup

500MBps cable connection with plenty of headroom; Unifi USX-Pro firewall/router; Unifi 48-port switch; all players and ROCK are on same subnet and VLAN; IGMP Snooping is on; all devices on hardwired ethernet. Library comprises 35400 tracks on NAS, 3677 in Qobuz.


Screenshot 2024-12-07 at 18.51.41
Screenshot 2024-12-07 at 18.51.411614×1534 91 KB

2

Topic was previously explored a year ago here inconclusively. New data this time.

I have recently noticed that interacting with the Roon control (eg looking for next album to play) seems to trigger dropouts. I can also get long response times eg 10-30 seconds to load an album page from Qobuz or the page can hang at “Loading album…”. Clicking on “Qobuz” can take 10-15 seconds to fill the page (is this normal?).

I therefore wonder whether the NUC running ROCK is at a limit when it tries to stream in Qobuz and push out Songcast. It is an Intel NUC7i7BNB, 3.5GHz, Crucial 8GB memory, 64Gb Sunbow M2 SSD.

Unfortunately ROCK does not provide any diagnostic tools to look at memory pressure, CPU load, disk errors, or temperature. Or is there somewhere I’ve not looked? Would a hardware problem with the NUC lead to the symptoms described?

Problem is intermittent - sometimes it can be hours before something goes wrong, then it will be every 30 seconds or so. And sometimes it stops the track altogether.

I have almost always seen this only on Qobuz streams but have today also encountered it on a 192k file played locally too.

I’ve seen this in the log during a dropout:

12/07 17:05:46 Trace: [Broker:Media] [dbperf] flush 0 bytes, 0 ops in 42 ms (cumulative 35316704 bytes, 14560 ops in 44545 ms)
12/07 17:05:47 Trace: [75] [Study] [Lossless, 24/192 QOBUZ FLAC => 24/192] [24% buf] [PLAYING @ 0:01/7:23] Suite : Judy Blue Eyes - Crosby, Stills & Nash
12/07 17:05:48 Info: [Broker:Media] [library] saved recent ProfileId=51e4de2a-5ec7-4f62-8999-030012de35a1 Time=12/07/2024 17:05:48 DataType=album Type=long_nav MetadataId=411001 ContentId=411001 LibraryId=1449007 Text= Genre=
12/07 17:05:52 Warn: [94] FTMSI-B-OE qo/A086CA74: poor connection kbps:5328.0 (min:6146.0)
12/07 17:05:52 Trace: [Broker:Transport] [Study] [Lossless, 24/192 QOBUZ FLAC => 24/192] [12% buf] [PLAYING @ 0:07/7:23] Suite : Judy Blue Eyes - Crosby, Stills & Nash
12/07 17:05:55 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:56 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:56 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:57 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:57 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:57 Trace: [Broker:Transport] [Study] [Lossless, 24/192 QOBUZ FLAC => 24/192] [1% buf] [PLAYING @ 0:12/7:23] Suite : Judy Blue Eyes - Crosby, Stills & Nash
12/07 17:05:57 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:58 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:58 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:58 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:58 Info: [7] [stats] 8580mb Virtual, 3686mb Physical, 1318mb Managed, 388 Handles, 85 Threads
12/07 17:05:58 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:59 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:59 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:05:59 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:00 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:00 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:00 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:00 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:01 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:01 Debug: [75] [prebuffer] sleeping in read -- this isn't good
12/07 17:06:02 Warn: [94] FTMSI-B-OE qo/A086CA74: poor connection kbps:4958.0 (min:6146.0)
12/0

I see quite a few of these too:

12/07 17:07:39 Warn: [64] [songcastdirect] [Linn Klimax DS] time discontinuity. Expected 109, Got 110
3

PreBuffer sleep in read is your core not being able to be served data from Qobuz quickly enough it’s nothing to do with the Linn side of things. I have had that myself on non Linn kit. It’s down to bandwith from Qobuz. This could possibly be a bad port or maybe ssd but most likely ISP related not routing you to nearest CDN for Qobuz or the local CDN is having issues.

Are you using your ISP DNS servers on your router ? If so what often works for some reason is changing these to use a more reliable 3rd party and secure service such as Google DNS 8.8.8.8, 8.8.4.4 or Cloudflare. 1.1.1.1 and 1.0.0.1. If you can change these on router it may help you.

Also check your cabling from router to NuC is getting the correct full bandwidth. You may need another pc for this.

As you mentioned Rock doesn’t give diagnosis, it’s why I and others have abandoned it for other small distros such as Dietpi as you can then at least test if it’s hardware or not.

1 Like
4

I will try that, but would this CDN hypothesis fit when my LUMIN and Pi players will stream 192k without dropouts - and Qobuz direct to Linn is ok?

I’ve run a bit error test on the cabling without issue.

Interesting. Not used DietPi before: if it will run in this NUC then perhaps I will try — at least I could then run a check in the SSD and memory.

5

Yes it does seem odd if others play without an issue, but perhaps the overhead to send it via Songkast just tips it over Roons small buffer size. But rebuffer is at the core not at the endpoint.

I take it you tried it at same time it happens on the Linn on others. When I have had it it’s also been problematic via none Roon as well. I’ve found Qobuz not the most stable platform via my ISP in the UK.

Dietpi It will run on pretty much any x64 machine if you download the x64 version.

6

I’ve seen stutters/sleeping in read with Roon on Ubuntu Server once when the server had a lot of I/O activity, mirroring its internal music SSD to another server while also playing to a (non-Linn) endpoint. The “sleeping in read” issue is typically the result of somewhat optimistic/incautious I/O programming, where “simple” blocking reads are used where more complex non-blocking I/O programming would be safer.

7

I had this strange vinyl replay sound similar to “popping” noise recently when listening to Qobuz via Roon.

I disconnected everything from my EE full broadband right down to my Linn Klimax DS/Organik/Utopik…

This seems to have cured the problem

8

Try Roon DSP downsampling to 96kHz for Qobuz 192kHz tracks. See if the same dropout occurs.

9

I don’t seem to have that option on a Linn player. (I can set local downsampling in Advanced audio properties of non-Linn players but not for any of our Linn machines.)

10

You could just set Qobuz settings in Roon to max 96/24 and test the same.

11

96 plays flawlessly that way. The problems only start when I play 192.

12

and can you play 192/24 ok to non Linn devices?

1 Like
13

Hi @anonymouse ,

This line is showing insufficient connection speed to Qobuz servers to buffer the track. I too suggest trying the DNS change, and verifying if 192/24 works for other zones. Let us know how this goes!

1 Like
14

Thanks. I will try the DNS - but I have already determined that 192k plays flawlessly on other players on the network so I doubt the issue is with incoming flow.

Could that log entry be written if the NUC was somehow struggling to pull input and push Linn Songcast simultaneously perhaps? What NUC fault might cause that?

15

Yes, LUMIN shows no errors at 192k.

16

Find out whether the NUC and Linn are connecting at Ethernet 100Mbps or 1000Mbps. There may be LED at the switch and the NUC network port to determine this.

17

NUC is running 1000Mbps; Linn is 100 but I believe it on,y has a 100Mbps port.

18

If you happen to have, or can borrow, an inexpensive unmanaged switch from Netgear or TP-Link, connect the Roon Server and Linn to this switch, with the uplink to your router (if it has a spare port, but probably not) or the 48-port switch.

This needs to be verified. Find out which generation of Linn you have and whether it really should be 100Mbps instead of 1000Mbps.

19

We don’t have one currently - might buy one but first feel the likely issue is the NUC itself

All three affected systems (Klimax 2015, Renew DS 2011, Sekrit DS-I) appear to have 100Mbps Ethernet in their specifications.

20

If that’s what you suspect, try to move the Roon Server to another computer (if you have one or can borrow one) temporarily.