Processing Speed ROCK -> DAC direct vs. ROCK -> Endpoint -> DAC

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

Core Machine is a NUC 7i3,
16 GB RAM
ROCK 1.0 Build 227
RoonSever 1.7 build 710
Music on external USB Drive, 1 TB

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

Gigabit Ethernet, all cabled
dedicated 8 Port GBit-Switch for RoonServer / Endpoint

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

Endpoint Raspberry Pi4 running VitOS / RoPieee with
Roon Bridge Version 1.7 build 571
USB into RME ADI 2 DAC

Description Of Issue

Setup A:
ROCK -> Ethernet -> Pi4 -> USB -> DAC
If DSP is enabled (Upsampling 44.1 -> 176.4), Processing Speed indicator starts out around 20, then slowly drops (20-30 sec) to around 14 and stays there.
This occurs both with VitOS an RoPieee running on the Endpoint, so I suppose, it doesn’t have anything to do with the specific implementation

Setup B:
ROCK -> USB -> DAC
If DSP is enabled (Upsampling 44.1 -> 176.4), Processing Speed Indicator starts out around 40 and stays there.

I was wondering,
a) why processing speed is so much lower in setup A than B
b) why processing speed drops during playing a track in setup A

Best Regards,
Roland v. Unruh

Hi Roland I see the same on a few of my Pi’s usually either when doing DSD256 or MAX PCM RATE (power of 2) which sounds similar to what you are doing.
But it is pretty much the same on VitOS and HiFiBerryOS. I don’t have a Ropieee plugged in at the moment but I thought it did it as well when I checked last.
It seems to take longer to work out the actual performance and just moves it down until it hits the correct level.
I can try a Ropieee later if you want to give you a definitive answer

Regards

Mike

Hi Mike,

good to hear that others have the same experiences in the matter.

I just recently migrated to ROCK. Before that, Roon was running on my NAS (Synolog DS218+. 6 GB RAM) as a core, feeding to the same Pi endpoint.

Funny enough, the processing speed indicator never showed the “dropping” behavior in this setup (NAS -> Ethernet -> Pi -> USB -> DAC), It also stayed around 20 despite the NAS’ CPU being far less powerful than the NUC i3.

So i was initially concerned about maybe having a performance issue with ROCK here, however the user experience with the NUC ist snappy and flawless (no lags, dropouts, stuttering etc.). But probably I’m misinterpreting the meaning of the processing speed indicator here?

Forgot to mention: My library is rather small (compared to others): 14k tracks.

Regards,
Roland

Processing speed means:

From the DSP FAQ:

Note that Roon currently runs the DSP engine on one CPU core per zone–so this reflects the load relative to consuming a full core. “2.0x” means you’re using 50% of one CPU core to play music in this zone.

Lets say, I’m playing Fleetwood Mac’s Rumors (24/96) and upsampling to 24/192. I’m getting 32.2x which means, I’m using (100/32.2) = 3.1055 or 3.1% of one of my 8 cores to do the upsampling.

So, the lower the number indicates MORE processing power is being used. So, in setup A, the processing usage starts at 5% of 1 core and increases to about 7.14% of 1 core. In setup B, the core starts and stays at 2.5% cpu usage.

Roland try it without upscaling or DSP disabled and in my experience there is no movement in processing speed.
I am surprised that you’re NAS coped with upscaling like that as my Synology never did (like you I migrated from NAS to ROCK)
Personally I see no problem with this as long as I am hitting 1.8x at a minimum.

Mike

Mike

@Rugby: Yes, that’s my understanding as well. Thats why i was initially concerned as the NUC seems to perform worse than the NAS on the same DSP task.

@Michael_Harris: Tried that with the following results:

  • On start and manual track skip the speed indicator shows the described “dropping” behaviour
  • if you don’t skip tracks manually, the indicator stays around 14 when the ne t track starts.

Maybe some caching thing going on here regarding buffering the processed data before it’s being send to the endpoint via Ethernet.

Not much of an issue as 14x still leaves plenty headroom.

What is still puzzling me is the huge difference in processing speed between the two setups (direct to DAC vs. endpoint).

Roland there are some threads about the caching that happens in memory when a song starts in Roon. That might have something to do with it, especially if it is playing from the Core itself.

I used to run my headphone DAC Amp from the Core, but after discussing with some knowledgeable people I moved the main headphone setup to a Pi and now they are all running off Pi’s.

I no longer consider the processing speed an issue as I only play DSD on one listening station and that brings it down to about 1.8x. everything else is at least 20x

Mike

Hi @Roland_von_Unruh,

Some fluctuation in the processing speed shouldn’t be worrying unless it’s causing dropouts or other issues. Your goal here is to keep processing speed over 1x to ensure that it finishes in time, and you are getting 14x which is still sufficient.

Thanks @noris for the feedback!
Performance is fine and stable, so I’m not worried.

Anyways, could you sheld some light on the huge difference in processing speed between
Setup A (NUC -> Endpoint -> DAC) : 14x
Setup B (NUC -> DAC direct): 40x

I have to commit, it’s more out of curiosity than actually being an issue.

Thanks,
Roland

1 Like

Hi @Roland_von_Unruh,

I can’t comment on why the speeds are different here, let me reach out to our tech team to see if they can comment.

Hi @Roland_von_Unruh,

I spoke to the team regarding this one. Processing speed is impacted when streaming over the network because it has to traverse network to reach the endpoint.

That processing speed is measuring how quickly Roon can keep the buffer filled, it is expected behavior that processing speed is lower when it has to cross the network compared to a direct connection.

If there are no issues and the processing speed doesn’t drop to around 1x then nothing to worry about.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.