Based on top output, it shows systemd cpu-freq-manage running. I have previously always disabled CPU frequency scaling on any RT-audio focussed laptop/machine, as it caused long-latency CPU stalls, leading to Xruns.
Linux RT kernel tools cyclictest can be used to measure jitter, and manually starting a workload like stress with CPU mode (sqrt for eg), would likely cause CPU to spin up/down.
Has this component been stress-tested? Does toggling the CPU frequency create latency/jitter on this CPU? Or even better - can it be proven that this does not cause latency/jitter?
cpu-freq-manage is a tool we did ourselves, it is just a bash script that checks temperatures (and optionally logs them as you find out) and if it gets too high, it will trigger “cooling devices”.
On the dwarf, that means reduucing CPU clocks. If things get really really hot, it kills off the system, but that should never happen.
It is not frequency scaling per se, and most of the time nothing will be done with that running. It is just there as precaution.
Ah, ok that makes sense. So should I expect to always see 1.3 GHz in the UI? With a default pedalboard (just the default gain plugin connecting inputs/outputs), it was showing 0.6 GHz, until I loaded a few cloud pedalboards and it went to 1.3 GHz?
1.3GHz should be there by default at all times, unless you click on it then it goes through all possible clocks.
(but it might appear as it does nothing, because clock speed only updates once every 5s)