4 Sep
2014
4 Sep
'14
3:04 p.m.
Hi,
after many years of wondering now and then I am curious what
qjackctl's display of "DSP load" is supposed to mean?
It must be some kind of CPU load, as there is no dedicated DSP in my
computer, so is it the cpu load of the jackd process?
Furthermore I wonder why the realtime "RT" indicator in qjackctl's
window is blinking about every 2 seconds. I do have -rt enabled.
Thank you for helping me to find answers to these things that are
puzzling me since quite some time.
best, P
4 Sep
4 Sep
4:01 p.m.
Am 04.09.2014 15:03, schrieb Peter P.:
Hi,
after many years of wondering now and then I am curious what
qjackctl's display of "DSP load" is supposed to mean?
It must be some kind of CPU load, as there is no dedicated DSP in my
computer, so is it the cpu load of the jackd process?
Furthermore I wonder why the realtime "RT" indicator in qjackctl's
window is blinking about every 2 seconds. I do have -rt enabled.
Thank you for helping me to find answers to these things that are
puzzling me since quite some time.
best, P
_______________________________________________
You could set the "RT" indicator to no-blinking in the setup widget in
the 3. tab.
DSP load mean the used CPU time before jack close the current audio
callback.
4:09 p.m.
On Thu, 4 Sep 2014 09:03:55 -0400
"Peter P." <p8rpp(a)aol.com> wrote:
after many years of wondering now and then I am
curious what
qjackctl's display of "DSP load" is supposed to mean?
It must be some kind of CPU load, as there is no dedicated DSP in my
computer, so is it the cpu load of the jackd process?
Furthermore I wonder why the realtime "RT" indicator in qjackctl's
window is blinking about every 2 seconds. I do have -rt enabled.
qjackctl's "DSP load" refers to how much of the latency given by
samplerate and buffersize has been used up by the audio processing
callback. That is to say if you have 2.9ms to finish the audio
processing, and the callback takes 1.45ms, then it will
show 50%, if it takes 2.9ms then it will show 100%. Note that it's an
average and not a maximum number, so conventional wisdom is to keep it
under 60% or so, to avoid xruns (ymmw).
The flashing RT just indicates that JACK is running in rt mode.
--
Joakim
4:21 p.m.
* Joakim Hernberg <jhernberg(a)alchemy.lu> [2014-09-04 10:09]:
On Thu, 4 Sep 2014 09:03:55 -0400
"Peter P." <p8rpp(a)aol.com> wrote:
Joakim, Hermann,
thanks to both of you for these excellent answers!
best, P
after many years of wondering now and then I am
curious what
qjackctl's display of "DSP load" is supposed to mean?
It must be some kind of CPU load, as there is no dedicated DSP in my
computer, so is it the cpu load of the jackd process?
Furthermore I wonder why the realtime "RT" indicator in qjackctl's
window is blinking about every 2 seconds. I do have -rt enabled.
qjackctl's "DSP load" refers to how much of the latency given by
samplerate and buffersize has been used up by the audio processing
callback. That is to say if you have 2.9ms to finish the audio
processing, and the callback takes 1.45ms, then it will
show 50%, if it takes 2.9ms then it will show 100%. Note that it's an
average and not a maximum number, so conventional wisdom is to keep it
under 60% or so, to avoid xruns (ymmw).
The flashing RT just indicates that JACK is running in rt mode. 
7:59 p.m.
On Thu, Sep 04, 2014 at 04:09:18PM +0200, Joakim Hernberg wrote:
Note that it's an
average and not a maximum number, so conventional wisdom is to keep it
under 60% or so, to avoid xruns (ymmw).
Last time I looked at that part of the Jack code it was
the maximum over the last N periods (with N = 1000 or so).
But things could have changed since then.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
5 Sep
5 Sep
3:44 p.m.
Fons Adriaensen <fons@...> writes:
On Thu, Sep 04, 2014 at 04:09:18PM +0200, Joakim Hernberg wrote:
There must be some averaging going on in there.
If I create a ton of synths in SuperCollider (driving up the DSP load), the
% load takes a few seconds to show the actual load. When I remove those
synths, it again takes a few seconds for the display to fall back to its
baseline level.
In any case, the display is definitely not an instantaneous reading.
hjh
Note that it's an
average and not a maximum number, so conventional wisdom is to keep it
under 60% or so, to avoid xruns (ymmw).
Last time I looked at that part of the Jack code it was
the maximum over the last N periods (with N = 1000 or so).
But things could have changed since then. 
5:39 p.m.
On Fri, 5 Sep 2014, James Harkins wrote:
Fons Adriaensen <fons@...> writes:
There is a balance between instantaneous reading and using cpu that your
audio could be using. I am not sure if average or peak is being reported,
but it is not suggested to run at 99% anyway. This is just a guide to
decide on latency setting and plugin inclusion. The real measure of cpu
use is xruns or not. This is just one more tool to help with no xruns.
--
Len Ovens
www.ovenwerks.net
Last time I looked at that part of the Jack code
it was
the maximum over the last N periods (with N = 1000 or so).
But things could have changed since then.
There must be some averaging going on in there.
If I create a ton of synths in SuperCollider (driving up the DSP load), the
% load takes a few seconds to show the actual load. When I remove those
synths, it again takes a few seconds for the display to fall back to its
baseline level.
In any case, the display is definitely not an instantaneous reading.
3529
days inactive
3530
days old
linux-audio-user@lists.linuxaudio.org
6 comments
6 participants
participants (6)
-
Fons Adriaensen -
hermann meyer -
James Harkins -
Joakim Hernberg -
Len Ovens -
Peter P.