Roon has trouble with large albums? Audio break-ups

Support
1

I was trying to listen to Bach’s Matthew Passion today and Roon was having a hard time of it. It is 2 discs and 68 tracks. It is 96/24. And it seemed like after a track change there would be dropouts and skips. It seemed to get worse the farther in I went until it started skipping tracks. That’s when I got disgusted and switched over to JRiver and was able to finish the album with no issues. I also replayed the offending tracks to make sure they weren’t corrupt…they weren’t.) This is the first large album I have played in full since starting to use Roon. I have played other 96/24 (and even 192/24 and DSD512 with Roon doing the conversion to PCM) but only on albums with a hand full of tracks. I use a microRendu (same unit for both Roon and JRiver) and everything is hard wired. I have a very beefy PC for the Roon core (again same PC for JRiver core.) Any ideas as to what’s wrong? I really like Roon and wan’t to keep using it but with some of the data issues (for classical) and now this I don’t know…haven’t’ deleted my JRiver yet.

John

2

I run Run core on a Linux NUC, serving to two microRendus over Cat 6. I mostly play albums, including mutidisc ones, at various PCM resolutions up to 192/24. Never any break-ups. One commonly reported problem is that some servers are configured to use jumbo IP frames, which seem to cause problems with RAAT and microRendu; the problem can be solved by making sure that MTU <= 1500 throughout your LAN.
https://community.roonlabs.com/t/playback-problem-with-both-sose-and-microrendu-in-roonready-mode-solved/11096

1 Like
3

Hi @John_Swanson_Swanson ----- Thank you for the report and my apologies for the frustration here.

May I kindly ask you to please provide me with the following information and we can try to get this sorted out for you :wink: Please see below.

  1. An expanded description of your current setup as seen here.

  2. Please briefly describe your network configuration/topology as well as providing insight into any networking hardware you may be implementing.

-Eric

PS - The advice offered by Fernando (@Fernando_Pereira :thumbsup:) in his post is sound. If jumbo frames are active in your setup I would recommend making sure that MTU <= 1500 throughout your LAN as suggested.

4

Roon version: 1.3 (build 218) stable (64 bit)
Core OS Windows 10 64 bit Version 1607 (OS Build 14393.953)
Device: Desktop PC Intel core i7 5960X 64 GB menory, 1TB ssd drive
Music store on NetGear ReadyNAS 516
Collection size 143926 tracks
Router ASUS RTAC3200
All units hardwired
Checked NAS, Router and PC and no jumbo frames and MTU=1500

Hope this helps.
John

5

Hi @John_Swanson_Swanson ----- Thank you for the follow up!

Based on the information you’ve provided, your core and NAS are hardwired to your ASUS RTAC3200 router, correct? I noticed you are also using a MicoRendu, can you give me some insight into this endpoint and any other endpoints you may be using? If there are multiple zones, can you verify how they are being accessed across your network?

-Eric

6

Eric,

No the Pcs, NAS, MicroRendu attach via switches and the switches attache to the router…sorry I left that out. The mircorendu is attached to my Meridian 861v8 via the usb adapter that came with the unit. No other zones (other than the PC speakers that I use occasionally on the core machine.

John

7

Hi @John_Swanson_Swanson ---- Thank you for clarifying that for me, very appreciated! Can you also provide the make and model of those switches as well?

Looking forward to your feedback!
-Eric

8

I’m quite sure I have the exact same problem, and it has taken many, many days to be confident that it’s a consistent issue, independent of hardware and operating system.

I’ve tried running the Core on a (“late 2012”) i5 Mac Mini, an Ubuntu Server VMware instance on a Windows 10 Core i5 3570K, natively, outside of VMware on Windows 10, and finally, as of today, that same Core i5 3570K running Ubuntu Server 17.04 on bare metal. In all cases these computers were doing nothing else besides acting as Roon’s Core server. All of the data storage quite fast (at worst an external USB 3.0 drive connected to the Mac Mini); right now the library on the Ubuntu 17.04 server is on a 12TB LVM volume comprised of 4 SATA III disks. Gigabit networking throughout; no Wi-Fi present at all in the signal chain.

They all exhibit dropouts with albums of multiple CD’s and/or many tracks. A single-disc, 11-track 16-bit/44.1kHz FLAC album? Not a problem. A 3-CD 16-bit/44.1kHz FLAC rip of Le Nozze di Figaro? Lots of dropouts. Same with an HDtracks download of what’s quite likely the same album John’s having issues with: Gardiner’s latest recording of the St. Matthew Passion with the English Baroque Soloists.

There are no jumbo frames configured anywhere on my network: everything’s running at the default 1500MTU. In all cases, the Ethernet interface statistics report zero errors.

And the problem is many, many times worse when I enable the DSP engine with upsampling.

9

Can you tell us your library size (in tracks), and also what you’re seeing for processing speed in Signal Path when you’re experiencing these dropouts?

10

I have 9,913 tracks in my library; 22582 including Tidal.

Playing a 16-bit/44kHz FLAC file with upsampling to 192kHz and bit depth conversion to 32bit shows a processing speed of 21.4x when dropouts occur and Roon skips to the next track entirely.

Core:

04/17 18:33:48 Trace: [transport/raatclient] [snd_rpi_hifiberry_dacplus] GOT [27] {"samples":47879,"status":"Dropout"}
04/17 18:33:48 Trace: [raat/audiosource] got NAK (20 seqs, 0 satisfied is_max=True)
04/17 18:33:48 Trace: [raat/audiosource] got NAK (20 seqs, 0 satisfied is_max=True)
04/17 18:33:48 Trace: [raat/audiosource] got NAK (20 seqs, 0 satisfied is_max=True)
04/17 18:33:48 Trace: [raat/audiosource] got NAK (20 seqs, 0 satisfied is_max=True)
04/17 18:33:48 Trace: [transport/raatclient] [snd_rpi_hifiberry_dacplus] GOT [27] {"samples":72441,"status":"Dropout"}
04/17 18:33:48 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
04/17 18:33:48 Trace: [zoneplayer/raat] too many dropouts. stopping stream

Roon Bridge:

04/17 18:33:48 Warn: [RAAT::snd_rpi_hifiberry_dacplus] dropout of 9600 samples at 14640007 [2]
04/17 18:33:48 Trace: [RAAT::snd_rpi_hifiberry_dacplus] [lua@0x71e033dc] [192.168.1.13:38017]  sent NAK [20 seqs]
04/17 18:33:48 Warn: [RAAT::snd_rpi_hifiberry_dacplus] dropout of 4345 samples at 14653952 [1]
04/17 18:33:48 Warn: [RAAT::snd_rpi_hifiberry_dacplus] dropout of 4743 samples at 14654464 [2]
04/17 18:33:48 Warn: [RAAT::snd_rpi_hifiberry_dacplus] dropout of 9593 samples at 14668800 [1]
04/17 18:33:48 Warn: [RAAT::snd_rpi_hifiberry_dacplus] dropout of 6144 samples at 14686720 [1]
04/17 18:33:48 Trace: [RAAT::snd_rpi_hifiberry_dacplus] [lua@0x71e033dc] [192.168.1.13:38017]  sent NAK [20 seqs]
11

Hrm, that all sounds fine.

Your initial post sounds like you’ve done some solid testing here, so I’m hesitant to say this, but this really does sound like networking. Have you tried simplifying the network, or playing to a different audio zone, just for testing?

If your Core has plenty of power (and it sounds like it does) and your storage is delivering the data on time (which I’m guessing it is, since you’ve tested with multiple Cores and a variety of storage configurations), the next thing I would look at is what’s happening after the Core – is there a switch or cable that all these configurations shared or, if they’re all playing to same audio device, is there another output you can try?

Based on the log snippet you gave us here, this really does sound like something isn’t performing as it should. We can work with you if none of the above seems possible based on the testing you’ve done so far. It’s also worth reading this article about dropouts.

I’m very confident we can figure this out. Thanks for the detailed report @Adam_Woodbridge!

12

Mike:

Thanks for your reply.

I’m not too sure if it’s possible for me to simplify the network configuration even further: The core, connected to a gigabit Ethernet switch that’s less than a year old, and from there right into the back of an RPi 3 that’s less than a month old, and a HiFiBerry DAC+ Pro installed. The Ethernet cabling is all brand new.

Also connected to that same switch is a 6-year old laptop (Core i7 2620M that’s had its CPU throttled way down to disable the chassis fan) running Roon Bridge on Ubuntu Server 17.04. Connected to it via USB is a Schiit Jotunheim. I’ve never used the DSP engine with it and have never experienced dropouts with it.

Two switches away from the Core in my bedroom is another RPi 3 connected by USB to a Schiit Modi Multibit. Never used upsampling and never experienced any dropouts.

Not having any issues with the RPi/Schiit setup in the bedroom sort of rules out an RPi issue, unless there’s some weird hardware issue with it that’s exhibited no other symptoms. No hardware errors in the logs, and ‘netstat -in’ shows zero TX or RX errors. It had dropouts running Raspbian and DietPI. I’ve also tried disabling the internal Ethernet interface and using a USB to gigabit Ethernet dongle. And running the core on two physically different computers and three different operating systems (macOS, Windows 10, Linux [btw, please port RoonServer to FreeBSD?]) rather rules the hardware/OS out of the picture, so far.

What I’ve observed so far, and I have the RPi/HiFiBerry setup playing almost continually throughout the day in my office, is that:

  • less dropouts, and a much faster connection from the client (macOS client on a MacBook Pro, iPad & iPhone) to the core on macOS (Mac mini, core i5) vs. either Linux or Windows. I almost never see the “waiting for core” message.

  • dropouts occur far more frequently on albums with many tracks, particularly those that contain a lot of short tracks.

  • dropouts on the RPi/HiFiBerry setup occur more frequently (by far) with 16-bit/44.1kHz FLAC files (not Tidal) upsampled by the core to 24-bit/192kHz. The core doesn’t go above 5% CPU utilization when dropouts occur. No I/O-wait bottleneck (always 0%). RAM utilization is 8% of 16GB. I can transfer data between the core and the RPi at up to 95Mbps, which is pretty good for a 100Mbps connection. Upsampled FLAC files only need about 1.9Mbps, anyway.

  • upsampling Tidal content to the RPi/HiFiBerry is impossible without getting tons of dropouts. I haven’t tried upsampling either FLAC or Tidal content to the Schiit USB DACs; something to try next.

  • dropouts occur far less frequently late in the evening, though there’s virtually no difference in the amount of network traffic. I’ve been playing 16-bit/44kHz (no DSP engine) FLAC (large album, lots of files) to the RPi/HiFiBerry, 16-bit/44kHz Tidal to the Schiit Jotunheim, and 16-bit/44kHz (no DSP) FLAC (same album as I’m sending to the HiFiBerry) to the Modi Multibit for the last hour (it’s 12:42am local time) with no dropouts (amplifiers turned off!). I’m running “tail -f /var/roon/RAATServer/Logs/RAATServer_log.txt | grep dropout” on all three Roon Bridges. I’ll let them run all night and check the logs in the morning.

  • dropouts occur less frequently when the desktop client isn’t left open.

Everything seems to point to a clock/timing or buffering issue.

-Adam.

13

My switches are Linksys SE2800 8-Port Gigabit Ethernet

Thanks,
John

14

To be clear, I wasn’t suggesting simplifying the network permanently, just to try and localize the problem. If you’ve recently added new cables, that’s a great reason to try moving stuff around and seeing if you can localize the problem to one part of the network.

I recently traced a week of issues at my place to a cable that went bad – the connection wasn’t down, just weirdly intermittent and occasionally very, very slow. @eric worked had two customers this week who ended weeks of troubleshooting by tracking down bad cables.

Network troubleshooting really is the worst, but I would be surprised if there was a deeper issue here. Not to say it’s not possible, just that your setup seems really solid and not particularly exotic – if there was something fundamentally wrong here, I suspect we’d be hearing about it more.

I’m going to have our team do some additional testing here, and I’ll let you know if anything comes up. In the meantime, @Eric will be able to work with you on this until it’s resolved.

As a starting point, can you confirm that this issue never happens with single disc albums? When you’re playing the troublesome albums, what are you seeing in Signal Path? Screenshots both with and without upsampling would be helpful here.

Thanks again Adam!

1 Like
15

Hi @John_Swanson_Swanson ---- Thank you for the follow up and confirming the make/model of the switch you’re implementing. My apologies for the slow response.

Can you verify for me if you play the same content that you are noticing this issue with out of the internal speakers of the desktop PC hosting your core, is the experience the same? Furthermore, being as you are pulling the content off of a NAS, have you tried temporarily moving some content to local storage to see if the issue reproduces itself with the NAS removed from the equation?

-Eric

16

//cc’ing @Eric

Mike:

I think I came at the source of this problem a couple of nights ago, and performance has been far more stable since then.

It looks like Roon relies quite heavily on DNSSEC to obtain extended zone information not included with typical DNS queries. I came across these messages in /var/log/syslog (on the Roon Core Server) occurring quite frequently during periods of dropouts:

Apr 18 21:18:43 mahler systemd-resolved[13209]: DNSSEC validation failed for question api.tidalhifi.com IN A: failed-auxiliary
Apr 18 21:18:43 mahler systemd-resolved[13209]: DNSSEC validation failed for question metadata5.roonlabs.com IN SOA: failed-auxiliary
Apr 18 21:18:43 mahler systemd-resolved[13209]: DNSSEC validation failed for question metadata5.roonlabs.com IN A: failed-auxiliary
Apr 18 21:20:55 mahler systemd-resolved[13209]: Server 192.168.1.1 does not support DNSSEC, downgrading to non-DNSSEC mode.

The server “192.168.1.1” is my router at home running BIND 9, resolving local host names and forwarding all other queries to my upstream Internet provider’s DNS servers. It definitely does not support DNSSEC.

At the same time those errors were occurring, ones similar to the following were appearing in RoonServer_log.txt:

04/18 23:31:26 Warn: Error in web request https://api.tidalhifi.com/v1/featured/recommended/playlists?countryCode=US&sessionId=e0fa2982-e3f2-4abe-8131-c694735c141c&&offset=0&limit=30: NetworkError (Error: NameResolutionFailure)
04/18 23:32:39 Warn: Error in web request https://metadata5.roonlabs.com/md/4/translatealbumid?uid=ef2ed5fe-0916-4421-a412-10fbf2f6171a&lid=&token=f874a58a-e768-4f21-8e8d-705f8e35ea9a&collection=tidal-us&albumid=79004d5730303033303132333434&collection=tidal-us: NetworkError (Error: NameResolutionFailure)

So, I removed 192.168.1.1 from /etc/resolv.conf and put Google’s public DNS servers in there instead: 8.8.8.8 and 8.8.4.4. Then I did a “systemctl restart systemd-resolved.service”. Name resolution errors continued, as did dropouts.

At this point I’m suspecting something’s wrong with Ubuntu’s systemd-resolved service, something that stands in the middle between the applications and the system’s configured DNS servers. A completely unnecessary daemon, but one that just had to be invented, because Linux.

Default /etc/nsswitch.conf on Ubuntu Server 17.04:

hosts: files resolve [!UNAVAIL=return] dns

Changed to:

hosts: files dns

No further name resolution errors. Also:

  • almost no dropouts with local content or Tidal, with DSP enabled or disabled. However, larger Tidal albums still drop out from time to time, especially when a new track starts playing.
  • browsing through the Roon interface is much faster
  • Roon still tends to have a complete meltdown if I’m upsampling a Tidal album and and then try and browse through a large Tidal album (like Georg Solti’s 15-CD Mozart operas collection). It’s almost like the sequence of timing between the Roon Core, Tidal, the HiFiBerry (RAAT) and the controlling client (MacBook Pro) falls apart.

So it would appear that having the “resolve” entry in /etc/nsswitch.conf was a major problem here, returning a “host not found” error to Roon with DNSSEC queries. Something to keep in mind as you put together a customized version of Linux for ROCK.

-Adam.

1 Like
17

Mike, @eric,

Congratulations on the latest changes applied to v1.3 update 223, as they’ve corrected all of the problems I’ve previously reported using Roon with my HiFiBerry DAC+ Pro/RPi 3 end-point: Playing the same Tidal album of Solti’s Mozart operas over the last 24 hours I’ve had no dropouts, even with upsampling pushed to 32bit-384kHz. And browsing through other Tidal albums via the Roon interface no longer results in dropouts.

I haven’t made any changes on my end, so…

Many thanks,

-Adam.

2 Likes