Error message when using Headphone EQ with DSD256 files (ref#TJHT9M)

[Achim_Weimer]

What’s happening?

· Other

How can we help?

· None of the above

Other options

· Other

Describe the issue

When I use the Headphone EQ (Focal Utopia 2022) with DSD256 files, I get an errormessage "An audio file is loading slowly. This may indicate a performance or hardware problem.".

DSD128 and DSD64 files play without problem (I use conversion to DSD256). No Problems with FLACs either.

It happens on my NUC 14 Pro (i7, with dietpi) as well as on my NUC 10 (i3, ROCK).

Describe your network setup

Router: Fritz!Box 7590 AX
some Netgear-switches
FiIleserver: QNAP TS-464
Stremer/DAC Auralic Vega G2

[Achim_Weimer]

[daniel]

Hi @Achim_Weimer,
Thanks for reaching out to us for help with this issue. I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.

However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.

First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.

[Achim_Weimer]

I reproduced the Error, it occured at 9:28 (CET), February 1 (and some more times shortly after that)
Album Rachel Podger, the muses restor’d, DSF DSD 256
Protean Quartet, Haydn, Almeida & Beethoven, DSF DSD 256

After that I disabled the EQ und played Podger some time without errors.

Then some DSD 128 with EQ (The new Appalachians), upsampled to DSD 256, no Problems.

[daniel]

Hi @Achim_Weimer,
Thanks for the timestamps. Unfortunately all but one of the logs we received from your server were blank. The one that we did get was from today. Can you check the logs on your Roon server and see if you have the logs from that timestamp? If you do please use the directions found here and send over a set of logs to our File Uploader.

[Achim_Weimer]

I sent the logs as
AchimWeimer_TJHT9M.zip
The Problem occured today at 8:17 am CET

[noris]

Hello @Achim_Weimer ,

it is strange but the logs you sent manually are also blank, this can sometimes occur when there are hardware issues. Have you by any chance checked your DietPi for failing hard drive/RAM issues? We are not able to see the NUC10 at all as being recently active as a RoonServer.

[Achim_Weimer]

The DietPi seems fine, no idea, why it doesn’t do logs.

I switched back temporarily to the NUC 10 (ROCK).
I uploaded todays logs as AchimWeimer_TJHT9M_2.zip
The error occured at February 12, 16:55 CET
I couldn’t provoke another error afterwards

The NUC10 is now offline again

[connor]

Hi @Achim_Weimer,

Thank you for your patience. We’ve reviewed the diagnostics provided and can see sample dropouts accumulated in the network path. RoonServer can’t distribute to the endpoint across the network without packet loss irreparably overwhelming the audio stream - with DSF256, the file is simple too large, and too many missing samples are re-requested from the server.

The “Slow Media” error we see in logs tends to be triggered when a network problem overwhelms the buffer - this is strong evidence of the Headphone EQ’s innocence in this case. The relatively massive size of the DSF256 files is why those tracks reveal this network symptom.

We can troubleshoot this issue by inspecting the network pathway between RoonServer and the Vega G2. However, we’d need to know the precise network topology involved.

[Achim_Weimer]

does this help?

[benjamin]

Hey @Achim_Weimer,

Thanks for the detailed graphic above! Are you able to temporarily bypass your switches and get a direct hardwire connection to your primary router and see if the same issues occur?

If they do, feel free to share the track name and we’ll take another look. Thank you!

[Achim_Weimer]

I connected ROCK, NAS and streamer directly to the router, the error occured on February 19, 17:59 (CET), The Muses Restor’d, Track 1
I temporarily switched to the ROCK to get logs. I uploaded them as
AchimWeimer_TJHT9M_3.zip
I will now reconnect everything as it was und return to the dietpi-Server

[connor]

Hi @Achim_Weimer,

Thank you for your thorough response and diligent troubleshooting so far. Here’s what we’ve found in the log set you shared.

Around the time indicated, the same pattern unfortunately recurred in ROCK logs. The below example is just one instance of at least five unnatural stoppages with DSD256 due to slow media in the log set.

02/19 16:59:04 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":242784,"status":"Dropout"}
02/19 16:59:05 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":154464,"status":"Dropout"}
02/19 16:59:05 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":261984,"status":"Dropout"}
02/19 16:59:06 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":173664,"status":"Dropout"}
02/19 16:59:06 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1099968,"status":"Dropout"}
02/19 16:59:07 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1230528,"status":"Dropout"}
02/19 16:59:07 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1753824,"status":"Dropout"}
02/19 16:59:08 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1353936,"status":"Dropout"}
02/19 16:59:08 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1773024,"status":"Dropout"}
02/19 16:59:09 Trace: [Worker (3)] [G2] [zoneplayer/raat] sync AURALiC VEGA_G2: realtime=131589572222055 rtt=0us offset=131317053222us delta=-1251us drift=-1353us in 123.919s (-10.925ppm, -39.332ms/hr)
02/19 16:59:09 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":1382736,"status":"Dropout"}
02/19 16:59:09 Trace: [Broker:Transport] [G2] [Enhanced 1.0x, DSD256 DSF => DSD256] [100% buf] [PLAYING @ 1:58/3:17] Sonata in D Major, HWV 371 Op. 1, No. 13: I. Affetuoso - Rachel Podger / Brecon Baroque / George Frideric Handel
02/19 16:59:09 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":4614624,"status":"Dropout"}
02/19 16:59:10 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":4233936,"status":"Dropout"}
02/19 16:59:10 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":4633824,"status":"Dropout"}
02/19 16:59:11 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":4502736,"status":"Dropout"}
02/19 16:59:11 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":4890576,"status":"Dropout"}
02/19 16:59:12 Trace: [.NET ThreadPool Worker] [AURALiC VEGA_G2 @ 192.168.1.101:41115] [raatclient] GOT [17] {"samples":5467104,"status":"Dropout"}
02/19 16:59:12 Warn: [Worker (2)] [G2] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
02/19 16:59:12 Trace: [Worker (2)] [G2] [zoneplayer/raat] too many dropouts. stopping stream
02/19 16:59:12 Warn: [Broker:Transport] [zone G2] Track Stopped Due to Slow Media

On the ROCK, we see the processing speed dropping below 1.0x in other cases during DSD256 distribution and playback:

02/19 16:18:05 Trace: [RaatSender] [G2] [Enhanced 0.8x, DSD256 DSF => DSD256] [100% buf] [PLAYING @ 0:00] Sonata in D Major, HWV 371 Op. 1, No. 13: III. Largo - Rachel Podger / Brecon Baroque / George Frideric Handel

At other times during DSD256 distribution and playback, the processing speed hovers between 1.0 and 2.0x.

The managed switch and any network settings are likely irrelevant here. The limiting factor is the ROCK’s computational processing ability with this massive format.

We don’t have verbose logging on the DietPi due to the logging errors referenced above, but you can check to see if the processing speed is dropping below 1.0x on that machine by opening Signal Path.