[Jack-Devel] jack dsp load calculation

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Kjetil Matheussen-2


On Sat, Dec 26, 2015 at 5:47 PM, Robin Gareus <[hidden email]> wrote:
On 12/26/2015 05:11 PM, Kjetil Matheussen wrote:

>> On which platform is that? with JACK?
>>
>>
> Just calling clock_gettime(CLOCK_MONOTONIC, &time) before and
> after processing audio locally in Radium. CPU numbers from jack is
> not shown in Radium.
>

Radium also runs on Windows and OSX, right?
Do you use glib functions or directly some low-level API?


On both Windows and OSX, it will use CLOCK_MONOTONIC if it is available.
If not, it will use mach_absolute_time() on OSX, and QueryPerformanceFrequency()
on Windows. If neither of these are available, it will use tsc.



OSX/mach is trivial, but Windows is probably the reason why jack2
currently does what it does..

Since Windows is not my main platform, I haven't looked at the numbers
enough to say much about the stability of it. But I don't think I have noticed anything weird.
(using Windows 7, Windows 8, and Windows 10).


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

John Emmas
In reply to this post by Robin Gareus
On 26 Dec 2015, at 16:49, Robin Gareus wrote:

> On 12/26/2015 05:27 PM, John Emmas wrote:
>>
>> Huh? You've already pointed out that any value higher than 95% gets
>> reported verbatim (i.e. without getting factored into any averaging). So
>> why will 100% not get reported correctly?
>
> Where did I say that?
>

A few days ago you said that xruns are caused by "short spikes" but that a short spike will only show up in the DSP reading if 3 conditions are met (one of which was that it would need to be > 95%).

What I'm saying is that the DSP reading (currently) isn't intended to display xruns.  It's only intended to give a general picture of CPU load.  If we want it to react to xruns (e.g. to turn red when an xrun occurs) we can achieve that very easily from within Ardour.  Modifying Jack (at least in the short term) shouldn't be necessary.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Robin Gareus
On 12/26/2015 06:45 PM, John Emmas wrote:

> On 26 Dec 2015, at 16:49, Robin Gareus wrote:
>
>> On 12/26/2015 05:27 PM, John Emmas wrote:
>>>
>>> Huh? You've already pointed out that any value higher than 95% gets
>>> reported verbatim (i.e. without getting factored into any averaging). So
>>> why will 100% not get reported correctly?
>>
>> Where did I say that?
>>
>
> A few days ago you said that xruns are caused by "short spikes" but
> that a short spike will only show up in the DSP reading if 3
> conditions are met (one of which was that it would need to be >
> 95%).

right, they're reported once in a blue moon :)

> What I'm saying is that the DSP reading (currently) isn't intended to
> display xruns.  It's only intended to give a general picture of CPU
> load.  If we want it to react to xruns (e.g. to turn red when an xrun
> occurs) we can achieve that very easily from within Ardour.

Yes, this is however not about Ardour. I don't know why you keep
bringing this up. There are a lot more jack-clients and control
applications out there.

All the other arguments I brought forward still stand.

> Modifying Jack (at least in the short term) shouldn't be necessary.

I'm not going to rush this. It's been nagging me for a few years already.

Since libjack aims to be API and ABI compatible, deprecating a call and
adding a new one must be done with great care.

If jack were to provide  min, max, average and stddev a client
application can do the appropriate thing..

Other considerations: should this become a callback API (don't miss a
value) like outlined by Florian earlier in this thread.  But I think
it's still too early to go into details like this until there is some
consensus what jackd should and should not do.

robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Joakim Hernberg-2
On Sat, 26 Dec 2015 19:14:52 +0100
Robin Gareus <[hidden email]> wrote:

> On 12/26/2015 06:45 PM, John Emmas wrote:
> > On 26 Dec 2015, at 16:49, Robin Gareus wrote:
> >
> > A few days ago you said that xruns are caused by "short spikes" but
> > that a short spike will only show up in the DSP reading if 3
> > conditions are met (one of which was that it would need to be >
> > 95%).  
>
> right, they're reported once in a blue moon :)
>
> > What I'm saying is that the DSP reading (currently) isn't intended
> > to display xruns.  It's only intended to give a general picture of
> > CPU load.  If we want it to react to xruns (e.g. to turn red when
> > an xrun occurs) we can achieve that very easily from within
> > Ardour.  
>
> Yes, this is however not about Ardour. I don't know why you keep
> bringing this up. There are a lot more jack-clients and control
> applications out there.
>
> All the other arguments I brought forward still stand.
>
> > Modifying Jack (at least in the short term) shouldn't be
> > necessary.  
>
> I'm not going to rush this. It's been nagging me for a few years
> already.
>
> Since libjack aims to be API and ABI compatible, deprecating a call
> and adding a new one must be done with great care.

IME the dsp load is a relatively useless measure as it's not really
related to the max value (which is where an xrun occurs)..  You could
very well have a system with a very low dsp load xrunning all the
time...

Maybe a nice idea would be similar to a mixer meter showing rms and
peak values, like that everyone could have their cake and eat it too ;)

Apart from that there is the xrun callback that indicates that an xrun
did indeed occur.  If we only had Jack2 to worry about, I'd suggest
leveraging jack2's excellent profiling code, which can give a very good
analysis of how the system performs.

Here is a link to an old paper from Letz, Fober, and Orlarey that shows
the wealth of information that could be gleaned about the graph and
it's timing in a JACK2 system.

http://www.grame.fr/ressources/publications/Jackdmp-ICMC2005.pdf

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Kjetil Matheussen-2
In reply to this post by Kjetil Matheussen-2


On Sat, Dec 26, 2015 at 5:56 PM, Kjetil Matheussen <[hidden email]> wrote:

Radium also runs on Windows and OSX, right?
Do you use glib functions or directly some low-level API?


On both Windows and OSX, it will use CLOCK_MONOTONIC if it is available.
If not, it will use mach_absolute_time() on OSX, and QueryPerformanceFrequency()
on Windows. If neither of these are available, it will use tsc.


Sorry, for this purpose, jack_get_time() is used, not that other function.
That other function is only used when it's important that get_time_of_day
is not used, and when it's okay if tsc is used directly.

I also see that QueryPerformanceCounter is used for jack_get_time().

I thought QueryPerformanceCounter should do the right thing though, but it seems a bit complicated:

"
Q: Is the performance counter monotonic (non-decreasing)?
A:Yes

Q: How accurate is the performance counter?
A:  The answer depends on a variety of factors. For more info, see 
"


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Joakim Hernberg-2
In reply to this post by Joakim Hernberg-2
On Sat, 26 Dec 2015 22:56:43 +0100
Joakim Hernberg <[hidden email]> wrote:

> Here is a link to an old paper from Letz, Fober, and Orlarey that
> shows the wealth of information that could be gleaned about the graph
> and it's timing in a JACK2 system.
>
> http://www.grame.fr/ressources/publications/Jackdmp-ICMC2005.pdf

Sorry, wrong link:
http://www.grame.fr/ressources/publications/Timing.pdf


--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Robin Gareus
In reply to this post by Joakim Hernberg-2
On 12/26/2015 10:56 PM, Joakim Hernberg wrote:
[..]

> IME the dsp load is a relatively useless measure as it's not really
> related to the max value (which is where an xrun occurs)..  You could
> very well have a system with a very low dsp load xrunning all the
> time...

exactly.

But if we add a new API, I would not mind if it also included a proper
statistical average (and maybe min,..) since there seems to be interest.

We might as well leave the old jack_cpu_load() code untouched, but I
think it should be changed to report the max.

> Maybe a nice idea would be similar to a mixer meter showing rms and
> peak values, like that everyone could have their cake and eat it too ;)

heh.

> Apart from that there is the xrun callback that indicates that an xrun
> did indeed occur.  If we only had Jack2 to worry about, I'd suggest
> leveraging jack2's excellent profiling code, which can give a very good
> analysis of how the system performs.

JackEngineControl::CalcCPULoad() already uses that API to calculate the
cycle duration.

My criticism is with the built-in pre-processing in that function.

@John: If libjack were to expose both RMS and peak, the client
application - in your case Mixbus - can do the same thing as jack
currently does: Display the max if some conditions are met and the
average otherwise and also filter the value ad lib, so nothing is lost.
It could even be some user-preference..

Do you see some issues with this approach?


@Joakim: Thanks for the reminder about Timing PDF. This shows that at
least on POSIX systems the measurement error is small and that there can
be spikes nearly twice as large of the average value.

Cheers!
robin

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

John Emmas
On 26 Dec 2015, at 23:05, Robin Gareus wrote:

> On 12/26/2015 10:56 PM, Joakim Hernberg wrote:
> [..]
>
>> IME the dsp load is a relatively useless measure as it's not really
>> related to the max value (which is where an xrun occurs)..  You could
>> very well have a system with a very low dsp load xrunning all the
>> time...
>
> exactly.
>

No, not quite...  you can have a system "displaying" a very low DSP load even though it's xrunning all the time.  But that problem is NOT caused by Jack's CPU load calculation.  Nor is it caused by the averaging strategy.

The averaging strategy was added to JackEngineControl::CalcCPULoad() to address a very specific problem - which it does address, very successfully.  Furthermore (read this bit carefully) it does NOT cause JackEngineControl::CalcCPULoad() to return a low reading when an xrun occurs.  If a client app is giving that impression, the problem lies within the client app.  And that's where it should be getting fixed.

To prove this point (assuming Ben Loftis agrees) I'd be quite happy to add such a fix to Mixbus.  And if Mixbus still displays low readings when an xrun occurs, maybe then we should consider modifying Jack.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Robin Gareus
On 12/27/2015 11:34 AM, John Emmas wrote:

> On 26 Dec 2015, at 23:05, Robin Gareus wrote:
>
>> On 12/26/2015 10:56 PM, Joakim Hernberg wrote:
>> [..]
>>
>>> IME the dsp load is a relatively useless measure as it's not really
>>> related to the max value (which is where an xrun occurs)..  You could
>>> very well have a system with a very low dsp load xrunning all the
>>> time...
>>
>> exactly.
>>
>
> No, not quite... you can have a system "displaying" a very low DSP
> load even though it's xrunning all the time.

How can one have buffer under/over-runs if there is sufficient time left
to process the buffers?



> The averaging strategy was added to JackEngineControl::CalcCPULoad()
> to address a very specific problem - which it does address, very
> successfully.

What is that? low readout for marketing? :-)

Some facts would be nice and an explanation of thoughts and that lead to
the current implementation. Why keep 32 cycles history? Why not a
rolling-average? Why add a first order low-pass filter after averaging
with a fixed time-constant of 0.5 ? Why 0.5 ?


> Furthermore (read this bit carefully) it does NOT
> cause JackEngineControl::CalcCPULoad() to return a low reading when
> an xrun occurs.  If a client app is giving that impression, the
> problem lies within the client app.  And that's where it should be
> getting fixed. To prove this point (assuming Ben Loftis agrees) I'd
> be quite happy to
> add such a fix to Mixbus. And if Mixbus still displays low readings when
> an xrun occurs, maybe then we should consider modifying Jack.
>

Why do you keep bringing up Mixbus all the time? This is about JACK or
more specifically libjack.

Control Applications (like qjackctl, Ardour, Cadence, Mixbus, ...) and
other clients which display the load are all users of the jack-api and
currently limited to a single convoluted value, for which I have not
heard a good argument for.

Would you mind commenting on or answering the questions from other emails?

eg.  What is lost - in your case for Mixbus - if jack were to report
both average and max?

best,
robin

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

John Emmas
On 27 Dec 2015, at 12:13, Robin Gareus wrote:

>
> How can one have buffer under/over-runs if there is sufficient time left
> to process the buffers?
>

This can happen (or rather, appear to happen) if the application isn't updating the buffer status frequently enough.  For example in one of your early emails you stated:- "At 1024fpp / 48KHz, 32 cycles corresponds to ~680msec. Most control applications only update the value every second or so."

In which case there are bound to be occasions when Jack flags up a high DSP reading which the client app misses.  However as I keep saying, this is NOT being caused by the averaging mechanism.


>
> Some facts would be nice and an explanation of thoughts and that lead to
> the current implementation. Why keep 32 cycles history? Why not a
> rolling-average? Why add a first order low-pass filter after averaging
> with a fixed time-constant of 0.5 ? Why 0.5 ?
>

I can't answer those questions.  The history buffer and LPF already existed.


>
> Would you mind commenting on or answering the questions from other emails?
>
> eg.  What is lost - in your case for Mixbus - if jack were to report
> both average and max?
>

If you're referring to Nedko's suggestion I've already stated that I think it would be a useful improvement.  But in the meantime, if users are hearing xruns (while they're seeing DSP figures around 40%) I'm simply pointing out that this is NOT due to the averaging mechanism.  And in any case, if you're referring to Mixbus3 users, those complaints weren't even about the Jack backend.!

Mixbus2 (which uses the Jack backend exclusively) has been around for at least 4 years.  Yet I can't remember a single user complaining about this.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Robin Gareus
On 12/27/2015 02:13 PM, John Emmas wrote:
> On 27 Dec 2015, at 12:13, Robin Gareus wrote:
>
>>
>> How can one have buffer under/over-runs if there is sufficient time left
>> to process the buffers?
>>
>
> This can happen (or rather, appear to happen) if the application
> isn't updating the buffer status frequently enough.
[..]

Ok, so you were still thinking about the *current* reporting mechanism.

Do you agree that this current behavior is not ideal?

> However as I keep saying, this is NOT being caused by the averaging
mechanism.

Right, it's caused by the overall semantics of that API, which is why
I'm saying that the API is not good.

>> Some facts would be nice and an explanation of thoughts and that lead to
>> the current implementation. Why keep 32 cycles history? Why not a
>> rolling-average? Why add a first order low-pass filter after averaging
>> with a fixed time-constant of 0.5 ? Why 0.5 ?
>>
>
> I can't answer those questions.  The history buffer and LPF already existed.
>
>>
>> Would you mind commenting on or answering the questions from other emails?
>>
>> eg.  What is lost - in your case for Mixbus - if jack were to report
>> both average and max?
>>
>
>
> If you're referring to Nedko's suggestion I've already stated that I
think it would be a useful improvement.

good. I must have missed that.

> But in the meantime, if users
> are hearing xruns (while they're seeing DSP figures around 40%) I'm
> simply pointing out that this is NOT due to the averaging mechanism. And
> in any case, if you're referring to Mixbus3 users, those complaints
> weren't even about the Jack backend.!

What use-case do you see in the exposing the average value? How do you
interpret the value? How is a user supposed to interpret it?


As developer I can see some value in it for regression tests (same app,
same machine, same settings) for development, but then again it's the
worst-case that really matters.

As user I'm interested how much more DSP I can safely add, the current
mechanism (average + thread-hold + filter) cannot provide any useful
measure. How do you propose to address this?


> Mixbus2 (which uses the Jack backend exclusively) has been around
> for at least 4 years. Yet I can't remember a single user complaining about
this.

Well, jack has been around much longer. How is that an argument?

best,
robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Joakim Hernberg-2
In reply to this post by John Emmas
On Sun, 27 Dec 2015 10:34:26 +0000
John Emmas <[hidden email]> wrote:

> On 26 Dec 2015, at 23:05, Robin Gareus wrote:
>
> > On 12/26/2015 10:56 PM, Joakim Hernberg wrote:
> > [..]
> >  
> >> IME the dsp load is a relatively useless measure as it's not really
> >> related to the max value (which is where an xrun occurs)..  You
> >> could very well have a system with a very low dsp load xrunning
> >> all the time...  
> >
> > exactly.
> >  
>
> No, not quite...  you can have a system "displaying" a very low DSP
> load even though it's xrunning all the time.  But that problem is NOT
> caused by Jack's CPU load calculation.  Nor is it caused by the
> averaging strategy.

I'd agree with this.  The measures are separate, and it's useful to
know approximately how much headroom you have left until exceeding the
deadline.  Not really related to xruns at all, until you start
exceeding a certain threshold.  Still it would be very useful to have
an indication of the max latency reached so far and not only an
average.  Personally I've been missing this for a long time.  I'd think
the best solution would be the addition of a new call that returns,
max, min and some kind of average of the graph's execution latency.

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Chris Caudle
In reply to this post by Kjetil Matheussen-2
On Sat, December 26, 2015 10:11 am, Kjetil Matheussen wrote:

>> One thing I'm not quite sure of, which is always apparent because all
>> the
>> > values are visible, is why there is such a large difference between
>> > minimum and maximum CPU usage. It's usually at least 4-10
>> > percentage points. I hope it's because of measurement
>> > errors.
>>
> Just calling clock_gettime(CLOCK_MONOTONIC, &time) before and
> after processing audio locally in Radium. CPU numbers from jack is
> not shown in Radium.


Maybe I misunderstood, but if the quote above refers to the same operation
taking different amounts of time, couldn't that be explained by
preemption? Sometimes the DSP operation gets suspended for kernel
housekeeping, which results in the end of the DSP operation occurring
later than at other times when it does not get preempted?

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Kjetil Matheussen-2


On Mon, Dec 28, 2015 at 4:44 PM, Chris Caudle <[hidden email]> wrote:

Maybe I misunderstood, but if the quote above refers to the same operation
taking different amounts of time, couldn't that be explained by
preemption? Sometimes the DSP operation gets suspended for kernel
housekeeping, which results in the end of the DSP operation occurring
later than at other times when it does not get preempted?

 
I don't know the kernel very well, but 4-10 percentage points sounds
a lot for kernel house keeping.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Chris Caudle
On Tue, December 29, 2015 2:54 am, Kjetil Matheussen wrote:
> I don't know the kernel very well, but 4-10 percentage points sounds
> a lot for kernel house keeping.

Speaking of percentage differences in the abstract is not very useful.
Check the period size in use and convert that percentage difference to an
actual time difference to see whether the time difference is reasonable.
Latency variations I have seen quoted are in the high three digit
milliseconds to over a second for a kernel with no preemption, multiple
tens of milliseconds for voluntary preempt (but not hard limited), and
around one millisecond or less for full RT patches.

Keep in mind that a lot of motherboards use system management mode for
things like checking temperature, and SMM preempts even the kernel, so no
matter which kernel variant you use that time is lost.  The only thing you
can do is try to disable options in the BIOS to reduce the time spent in
SMM.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack dsp load calculation

Joakim Hernberg-2
On Tue, 29 Dec 2015 14:11:33 -0600
"Chris Caudle" <[hidden email]> wrote:

> Keep in mind that a lot of motherboards use system management mode for
> things like checking temperature, and SMM preempts even the kernel,
> so no matter which kernel variant you use that time is lost.  The
> only thing you can do is try to disable options in the BIOS to reduce
> the time spent in SMM.

You can use the hwlatdetect script included with the rt-tests package
together with a kernel module to get an idea about how bad SMM/SMI
affects your system (provided that it has a well working TSC
implementation).

My i7 desktop has a kernel scheduling latency well under 100us, while
my laptop seems to come in at 120us or so (both -rt patched).

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12