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.
jackfreqd can be distributed in terms of the GNU General Public License.
Stop or remove existing CPU frequency scaling daemons from the system. and make sure your system supports userspace freq. scaling (
sudo modprobe cpufreq_userspace).
git clone git://rg42.org/jackfreqd cd jackfreqd make sudo make install sudo /etc/init.d/jackfreqd start
To launch it on bootup you need to create symlinks in
/etc/rc?.d/. e.g by running
update-rc.d jackfreqd defaults.
On debian you can automate that:
git clone git://rg42.org/jackfreqd cd jackfreqd git checkout -b debian origin/debian git-buildpackage --git-upstream-branch=master --git-debian-branch=debian -rfakeroot sudo dpkg -i ../jackfreqd_*.deb
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.
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…
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
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
Sounds like a good solution and strategy and it would be very useful to have…