jackfreqd

Inspired by discussion with Fernando Lopez-Lezcano on LAU and jack-dev. I became motivated to create a tool that changes the CPU frequency according to DSP-load in order to address an issue on multi-core systems where system-load may still be too low for a default CPU governor to react while DSP load is already at the limit, causing x-runs.

jackfreqd is heavily based on powernowd. Instead of taking CPU load as parameter for deciding on the CPU frequency jackfreqd uses JACK DSP-load and jackfreqd only supports the powernowd's aggressive mode 1). Optionally jackfreqd can also take CPU load into account which comes in handy when the JACK-daemon is temporarily unavailable or if frequency-scaling should also be done for on non-audio processes.

In order to gain access to modify CPU-speed and do so quickly, jackfreqd needs to be run as root. jackfreqd includes support to assume a given user-id which runs the JACK-daemon, and also to auto-detect a running JACK instances and (re) connect to it.

Source

In Feb 2020 Oleg Samarin has taken over maintenance. The repo was moved to github, please update your URL:

jackfreqd can be distributed in terms of the GNU General Public License.

Usage

Consult the man page man jackfreqd or run jackfreqd -h for details.

Note that, while CPU frequency scaling is usually not a problem with JACK, Front-Side-Bus frequency scaling and PCI power-saving often causes x-runs with JACK. The latter can usually be disabled in the BIOS.

Discussion with Fernando

Fernando:
To reproduce the issue you need to be quite “tuned” (in the wrong way),
you need an application that uses two cores at about 50-60% and then you
change the connections so that they have to execute in series in jackd.
Before the connection change everything is fine as they execute in
parallel. After the connection no cores trigger the cpuspeed scaling but
jackd misses the deadline anyway… In my case it was even worse, when I
set the speed to “high” it would almost work - doing other things would
trigger xruns and then to cap it off stopping cpuspeed would push things
over the edge and I would get no xruns. Bad luck in a way…

Robin:
yes, there is a short delay when the CPU switches speeds, but it should
be irrelevant. I intent 'jackfreqd' to do the same as you do: switch to
“high CPU performance” when starting serious audio work and go back to
low-power only at the end of the session.

It uses very small High- and Low-watermarks: as soon as the DSP load
goes above 50% : CPU freq switches to 100%.
If and only if DSP load drops below 10% the CPU-speed is reduced by
one-step again.

There can be a x-run at the start of the session: If you manage to go
from <50% to >100% DSP load in one step.. (since 0.0.2 jackfreq checks
DSP load periodically and on each JACK graph change. The algorithm can
be optimized: lower the periodic update period after each graph-change
for a few cycles..). I still need to play around to find good defaults
for the high/low watermarks, etc.. For the time being I'm aiming at a
proof-of-concept.

Fernando:
Sounds like a good solution and strategy and it would be very useful to have…

1) Aggressive mode changes frequency by a sawtooth function. The system immediately jumps to the highest frequency whenever usage exceeds a given threshold (high-water-mark), and decreases by “step” Hz as usage drops below a low-water-mark
 
oss/jackfreqd/start.txt · Last modified: 28.02.2020 13:56 by rgareus