The confusion is something I’ve spoken about earlier, and I’ll reiterate it here. This is one of the reasons we tell everyone to not use this processing speed as some form of efficiency metric.
In the case of the network output, the audio enters the network stack straight out of Roon, which is a system optimized for gigabit networks. There is very little that happens in the operating system because of fast paths.
In the case of a USB output, the audio enters the audio system of the operating system. Depending on your system (Core Audio, ALSA, WASAPI, ASIO, etc…), the various drivers handle this audio data and send the data to your devices. There may be mixers and other items in that pipeline, and depending on how you speak to/configure the audio system, there could be some non-trivial CPU usage. Also, audio drivers tend to be less CPU-optimized because the bandwidth being sent through them is so low.
With a reasonable audio stack (and no funny business like mixers or DSP), and an ethernet port built into the motherboard (with no other funny business like VPNs), I would expect the USB audio and the network audio to be similar in terms of CPU usage on the Core machine. If there were any differences, I would bet the performance of the network to better, just ever so slightly.
So, how does this explain your screenshots?
First, let’s clarify what your screenshots are showing. The “processing speed” is clearly different, using the same hardware for the Core, playing the same content. The only difference is a network-connected audio device vs a USB-connected audio device. However, it is not telling you how much processing is being done or the load on the CPU. I know that’s what everyone likes to believe, but it’s just not true. It’s telling you a ratio of how much time is spent processing the audio in Roon, to the amount of CPU time Roon has been given by the operating system.
How are these 2 things different? Well, CPUs are not static in performance, energy consumption, and heat dissipation. Roon OS scales the CPU performance to run as cool and quiet as possible while maintaining Roon’s workload. Many other operating systems do too.
When the OS tells the CPU “hey, we aren’t very busy right now, you can run slower, which will make you stop sucking up so much power and dissipating lots of heat”, the amount of CPU time available to Roon will be lower (for obvious reasons). The amount of work that needs to be done to process that audio will remain stable, but the time to do it will also increase, again because the CPU is running slower.
The ratio of the processing time is like this: “(total amount of cpu time roon has) / (time spent processing audio)”.
As mentioned above, when the CPU is slowed, the total amount goes down and the time spent processing audio goes up, which would make the value of this ratio go down.
You are seeing lower processing speed because either because:
- the network-path is more efficient compared to the USB-path that it allows the CPU to go so much slower
- the USB-path is keeping the CPU running faster
- the network-path is consuming more CPU
I think the confusion comes because the 3rd item is the obvious one, but most likely it’s a combination of the first two.
You can easily rule out the 3rd item by running more zones. If your performance says 3.7x, when you run 4 streams, it should go below 1.0x. If it doesn’t, it must be the first 2 items in that list above.
So why have the processing speed at all? It’s a ballpark multiplier. It matters a lot when your multiplier is less than 2.0x, but it matters less and less as you go higher.
We actually just hide it at some high enough point because there is zero meaningful information that can be ascertained from looking at it.