Frequent dropouts / loss of output after upgrading to Roon 1.7 build 667

[Keith_Bernard]

Core Machine (Operating system/System info/Roon build number)

Roon Nucleus Rev B with WD Blue 3D NAND SATA SSD 1TB installed, OS Version 1.0 (build 227), Roon Server Software Version 1.7 (build 667)

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Netgear Orbi WiFi 6 System (RBK752) AX4200: The router is on another floor; the satellite is connected to the Nucleus by a Mediabridge Cat7 Ethernet cable, dual-shielded, 10Gbps, 5’ length.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Nucleus -> StackAudio LINK II via Moon Audio Silver Dragon USB -> Focal Arche via Silver Dragon USB

Description Of Issue

Once Focal released the firmware update to work with Linux devices in August, this setup has been running flawlessly. However since I upgraded to Roon 1.7 build 667 on October 19, I have experienced this problem every day. Essentially after the end of a session and the Arche goes into standby for 5+ hours, when I wake the Arche and start playing content again, one of two things happens: Roon will show that the content is playing to the Arche (either local files or TIDAL), but there is no output to the headphones - this is the one of two things that happens most frequently; the other thing that happens less frequently is that Roon will quickly (less than a second each) skip through each track in the queue. That’s what would happen with the Arche prior to the firmware update in August, but it hasn’t done that since until now. Also there have been no other changes to the Arche since August. These problems also occur if the LINK is out of the chain and the Arche is connected directly to the Nucleus via USB.

At the office in another setup, I have also been getting dropouts when streaming TIDAL through Roon, Audirvana, or the TIDAL app itself. It was far worse with the TIDAL app (all running on a 2020 i5 iMac), so I thought the TIDAL content might be causing a problem with the home setup. Last night’s test (I’ve run probably over a dozen tests to try to isolate this) was to clear the queue so no TIDAL content was lined up, let the Arche go into standby, and this morning I wanted to test the output by playing local content instead of TIDAL. Once again I had no output. I forced the Arche into standby again and woke it up as sometimes I still have output if the standby period has been relatively short. After waking the Arche, I am now just getting the file-skipping issue with both local and TIDAL content.

To restore output, I typically go through a myriad of power cycles of the devices in the chain and reconnecting cables until output is restored. Despite the frequent times I have had to do this (and have restarted the Roon software and rebooted the Nucleus as well), I still haven’t found that magic sequence of steps to restore output since it seems to be different every time.

I’m at a loss of what else I can try. Since this all began after the 667 build, I wanted to check with support to see if there is anything in that build that could be causing this. Please let me know what additional information I can provide to help you troubleshoot this. Thank you.

[Keith_Bernard]

One more test to rule out if TIDAL is the issue: Last night I logged out of TIDAL in Roon, and I had local content playing successfully before ending the session and letting the Arche go into standby. This morning I woke the Arche and started playing the local content that was in the queue. Once again I have no output.

I have tried to rule out all other reasonable factors, but it seems pretty squarely related to the 667 build since this began with that build and I had no problems prior to then. Please let me know if there’s anything I can do to help you troubleshoot this.

Attaching screenshots of the signal path and audio settings if that helps.

[Fernando_Pereira]

Have you tried to connect the Arche directly to the Nucleus via USB to test whether this has something to do with the LINK ||? Also, your setup description is a bit puzzling: it seems that you have Nucleus > USB > LINK II > USB > Arche. What is the point of interposing the LINK II that way? I’d understand if the LINK II was being used as an Ethernet streamer, on the same LAN as the Nucleus, but using it was a USB repeater seems like (potentially bug-inducing) overkill.

[Keith_Bernard]

Hi Fernando. Yes, I have tried this without the LINK in the chain, and I had the same results. The LINK is being used for USB detox, not for streaming, and it improves the sound.

[Keith_Bernard]

Hello @support

Based on your responses in some similar threads, I can confirm that the issue does not happen if I continue playback to the System Output on my iMac, but when I switched the zone to the Arche after these past several hours that it was in standby, I still didn’t have output while the track was playing.

Here is a link to my log files.

Sync | Secure cloud storage that protects your privacy

I have also noticed that when this happens, if I let the Arche go back into standby and wake it back up shortly thereafter, then I have output right away. The log files are up through the point of failure today. If you need another set that includes the restoration of output, let me know and I’ll go through this cycle again and capture the latest logs at that time.

Please let me know if you need anything else.

Thanks!

Keith

[noris]

Hi @Keith_Bernard,

Thanks for reaching out and for sending the log files ahead of time, it is very appreciated!
Let me get these logs over to our technical team for review and see if they provide more clues.

[Keith_Bernard]

No worries! Thanks for looking into this.

[Keith_Bernard]

@noris, you can close this ticket. While I was testing the issue with some other equipment, I decided to go with a different DAC/amp. I’m in the process of selling the Arche. I hope the log files were at least helpful in identifying the problem if others are running into it, too. Thanks.

[noris]

Hi @Keith_Bernard,

Thanks for the update here, yes this thread will indeed be useful if others have this issue with their Link II + Focal setup.

I spoke to our team about this case and it looked as if the Link II tried to set up for audio playback and failed. We tested a LINK we have in the lab with a different USB DAC and it worked as expected.

This case was probably one for the Focal team to also help investigate, but since you replaced the DAC, we can close this one.

[Keith_Bernard]

Gotcha. I was also getting the same issue while the LINK was not in the chain. In fact for the first three days that this was occurring, the LINK was not in the chain. Nevertheless.

Thanks again.