if(($ACT == 'edit' || $ACT == 'preview') && $INFO['editable']){ ?> } else { ?> } ?>
This shows you the differences between two versions of the page.
oss:jackfreqd:start [13.12.2010 02:01] rgareus |
oss:jackfreqd:start [28.02.2020 13:56] (current) rgareus |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== jackfreqd ====== | ====== jackfreqd ====== | ||
- | Inspired by discussion with Fernando Lopez-Lezcano on [[http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-December/074539.html|LAU]] and [[http://permalink.gmane.org/gmane.comp.audio.jackit/22839|jack-dev]]. I became motivated to create a tool that changes CPU frequency according to DSP load to address the 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. | + | Inspired by discussion with Fernando Lopez-Lezcano on [[http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-December/074539.html|LAU]] and [[http://permalink.gmane.org/gmane.comp.audio.jackit/22839|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 [[http://www.deater.net/john/powernowd.html|powernowd]]. Instead of taking CPU load as parameter for deciding on the CPU frequency ''jackfreqd'' uses [[http://jackaudio.org|JACK]] DSP load and it only supports the powernowd's //aggressive// mode ((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//)). 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. | + | ''jackfreqd'' is heavily based on [[http://www.deater.net/john/powernowd.html|powernowd]]. Instead of taking CPU load as parameter for deciding on the CPU frequency ''jackfreqd'' uses [[http://jackaudio.org|JACK]] DSP-load and ''jackfreqd'' only supports the powernowd's //aggressive// mode ((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//)). 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. | 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. | ||
Line 9: | Line 9: | ||
===== Source ===== | ===== Source ===== | ||
- | * [[http://rg42.org/gitweb/?p=jackfreqd.git|Repository, Changelog]] | + | In Feb 2020 Oleg Samarin has taken over maintenance. The repo was moved to github, please update your URL: |
- | * %%git://rg42.org/jackfreqd%% | + | |
- | * [[http://rg42.org/gitweb/?p=jackfreqd.git;a=snapshot;sf=tgz|snapshot]], [[http://rg42.org/gitweb/?p=jackfreqd.git;a=snapshot;h=debian;sf=tgz|debianized source]] | + | * <del>[[http://rg42.org/gitweb/?p=jackfreqd.git|Repository, Changelog]]</del> |
+ | * https://github.com/oleg68/jackfreqd | ||
''jackfreqd'' can be distributed in terms of the [[http://www.gnu.org/licenses/gpl2.html|GNU General Public License]]. | ''jackfreqd'' can be distributed in terms of the [[http://www.gnu.org/licenses/gpl2.html|GNU General Public License]]. | ||
- | |||
- | ===== Installation ===== | ||
- | |||
- | Stop or remove existing CPU frequency scaling daemons from the system. | ||
- | |||
- | 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 | ||
===== Usage ===== | ===== Usage ===== | ||
Line 41: | Line 23: | ||
===== Discussion with Fernando ===== | ===== Discussion with Fernando ===== | ||
- | + | >>> //Fernando:// | |
- | >> To reproduce the issue you need to be quite "tuned" (in the wrong way), | + | >>> 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 | + | >>> 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. | + | >>> change the connections so that they have to execute in series in jackd. |
- | >> Before the connection change everything is fine as they execute in | + | >>> Before the connection change everything is fine as they execute in |
- | >> parallel. After the connection no cores trigger the cpuspeed scaling but | + | >>> 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 | + | >>> 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 | + | >>> 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 | + | >>> 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... | + | >>> 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 | + | >> 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 | + | >> 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 | + | >> "high CPU performance" when starting serious audio work and go back to |
- | > low-power only at the end of the session. | + | >> low-power only at the end of the session. |
- | > | + | >> |
- | > It uses very small High- and Low-watermarks: as soon as the DSP load | + | >> It uses very small High- and Low-watermarks: as soon as the DSP load |
- | > goes above 50% : CPU freq switches to 100%. | + | >> goes above 50% : CPU freq switches to 100%. |
- | > If and only if DSP load drops below 10% the CPU-speed is reduced by | + | >> If and only if DSP load drops below 10% the CPU-speed is reduced by |
- | > one-step again. | + | >> one-step again. |
- | > | + | >> |
- | > There can be a x-run at the start of the session: If you manage to go | + | >> 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 | + | >> 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 | + | >> DSP load periodically and on each JACK graph change. The algorithm can |
- | > be optimized: lower the periodic update period after each graph-change | + | >> 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 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 | + | >> for the high/low watermarks, etc.. For the time being I'm aiming at a |
- | > proof-of-concept. | + | >> proof-of-concept. |
- | > | + | >> |
+ | > //Fernando:// | ||
+ | >Sounds like a good solution and strategy and it would be very useful to have... | ||
{{tag>audio development floss jack}} | {{tag>audio development floss jack}} |