Those were the original QX-5 specs, but I’ve recently upgraded to the new USB input board that doubles those numbers. Plus it allows native DSD. That didn’t change the dropout issue unfortunately.
I see. To what I read about SonicTransporter i9 (was really thinking of it at one point) it should have enough juice for decent DSD playback, yeah. Clear on DAC upgrade. So it seems from specs you are fine.
Another comment to the settings screen, in SDM your rate limit is set to DSD256x48 = 12288000… again this may be not an issue, but still. Can x48 rates present the issue in your set up?
Sorry, these are just guesses, really. No solid idea, unfortunately.
Thanks for the suggestions. The Ayre DAC does indeed do DSD 256x48. I think I’ve tried everything. I’ve lowered the rate by half just now, to DSD 128, but I still get dropouts.
Need further information: version of OS? version of Embedded?
1 Like
The latest available versions in all cases. SonicOrbiter 2.8 on ST and Rendu. HQPlayer NAA 4.2.0. Roon 2.8 (970).
Which Linux distribution you use? Type of kernel (normal, low latency or real-time? Which type of HQPe you run (SSE2 or AVX2)? There’s so many combo you really need to provide such detailed info for finding the culprit.
And also check your computer’s BIOS setting. Did you turn off hyper threading? Turbo boost? Even limited the CPU frequency?
And most importantly did it run normally before you upgrade your USB controller of your DAC? Have you tried USB direct connection to your computer for verifying the new board is ok?
1 Like
None of the things you mentioned are user accessible on the SonicTransporter. I had the problem both before and after upgrading USB boards, and also with a different DAC. I haven’t tried a direct USB connection. I’m not even sure it’s possible with the SonicTransporter.
Have you reached out to @agillis at Small Green Computer? He’s very active and helpful on this forum on issues with their gear.
1 Like
I think so, a long time ago. I may try again. I’ve also tried Jesus, since I suspected the opticalRendu was the problem. He said no. All I know is that I think I’ve tried everything. The bottom line is that Roon on its own works, including at higher sampling rates. But as soon as I use HQPlayer, the problems begin.HQPlayer can sound great, but the halts and dropouts take me out of the music too much to enjoy. I’ve probably spent enough time on this.
HQPlayer works fine for many of us, but every configuration is different. From recent experience with my i9-11900 fan-cooled HQPlayer server, I’m a bit skeptical that a fanless like the SonicTransporter i9-10900 can do DSD256 with commonly suggested configurations (mine: 1x = poly-sinc-gauss-xla, Nx = poly-sinc-gauss-hires-ip, modulator = ASDM7ECv2, rate = 12288000) over a long period without overheating and going into thermal throttling that will produce sound glitches.
1 Like
Try connecting your DAC directly to your sonicTransporter, instead of going through Rendu.
Usually if you get such dropouts in a setup like yours, it is due to networking problem between sonicTransporter and Rendu. Since Rendu hardware has limited network bandwidth capacity, it requires properly functional ethernet flow control (802.3x). This is also needed for reliable functioning in any case. Otherwise there can be too much packet loss. Flow control ensures that there is no packet loss.
On a gigabit network, Rendu hardware can reach 400 Mbps speed, but only when flow control is properly functioning. Otherwise the achieved bandwidth can fall well below 100 Mbps due to packet losses and resends.
4 Likes
Thanks very much Jussi. I’ll see if I can figure out how to bypass the OpticalRendu.
Is it more difficult to send the data that HQPlayer processes, compared to that from Roon, using Roon sampling? I’m trying to understand why Roon to Roon Ready on the Rendu works.
Roon uses different kind of network traffic pattern. And in addition Roon artificially limits the bandwidth usage as a hack to work around such network issues. The issue still exists, but it is less visible.
I’m not fond of brushing such things under the rug by making hacks, since the packet loss issue would still exists, just with less pronounced network stalls.
This is documented in NXP’s iMX6 datasheet and errata document:
802.3x Flow Control is also known as pause frames. This functionality is auto-negotiated by involved networking equipment. However, it requires that the networking equipment supports it. For example if you have a smart switch involved, this functionality is configurable. Default settings depend on manufacturer and switch model (and sometimes firmware version). So if you are using a smart switch, you always need to carefully go through the configuration. You cannot expect that such would work properly out of the box with default settings.
4 Likes
Is the opticalrendu connected directly to the SonicTransporter via fiber? Or, does the opticalrendu connect via a switch SFP port then on to the Sonic transporter.
I’ve tried both ways. Using fiber from the SonicTransporter directly to the opticalRendu and also through an EtherRegen. No difference with the issue, but I use the EtherRegen because it sounds significantly better.
Thanks for the thorough explanation Jussi. Much appreciated.
Ok, I’ve removed the OpticalRendu and connected the SonicTransporter directly to the DAC. I changed the HQPlayer configuration to ALSA. Now it plays fine for a few tracks and then stops. The only way to get it to play again is to press “Apply” in the HQP config screen. So perhaps the OpticalRendu isn’t the problem after all.
Are you sure your license key is properly uploaded ?
If not, it runs in trial mode and will stop every 30mins
In trial mode, I get one dropout every 30mins too. Usually a couple of minutes in to the 30mins, I get a “Roon has lost control of the audio device” message.
Is this a hardware issue, or network issue? Is this part of the trial mode?
Is your Roon Core running on WiFi ? And HQPlayer machine ?