Linux audio cpu load

Questions
#1

I’m trying to convert to Linux after having used Macs since forever. I’m running Manjaro on a Razer Blade 15 (2018) with an i7 8750H 6 core processor which, at least in theory, should be faster than my MB Pro late 2016. I’ve tweaked the jack settings and the system according to realtimeconfigquickscan and everything seems fine functionally. However, just booting the server in sc gives me a cpu-load of almost 3%. My MB Pro has something like 0.01%. I do realize that i might be looking at something different in Linux though, since this cpu load value seems to be derived from jack. I.e. starting another jack client increases the value even in sc. So, what am i looking at? Is SC on OSX showing me the cpu load of scsynth only, i.e. i shouldn’t compare these numbers?
And is a 3% “idle” load resonable in sc on linux or are there things to check/optimize?

Also tried benching to check the speed of sclang with this:

bench{
	10000.do{
		789/3;
	};
}

My Razer delivers
time to run: 0.00047562600002493 seconds.
-> 0.00047562600002493

My MB Pro is twice as fast with something like
0.0002 seconds

Why? I would have expected the opposite.

#2

Yes, that’s right. It’s the total percent of the time taken to calculate the audio for this hardware buffer vs the duration of one hardware buffer. If your hardware buffer is small, for low latency, 3% isn’t out of the question.

If other audio apps are busy, it will affect SC’s ability to complete on time, so the total load is a relevant measure.

I don’t know if the CPU usage number in macOS reflects only SC or the total.

Are your soundcard settings comparable between the two environments?

How about the CPU reading when you’re stressing the server?

The soundcard’s interrupt thread priority is also a factor. I’d hope that realtimeconfigquickscan would get that right but… who knows…?

No idea about sclang speed there.

hjh

#3

Doh… forget about the last part. sclang is actually faster on my Razer if i have the same number of do-iterations… :roll_eyes: