[Jack-Devel] jack dsp load calculation

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

[Jack-Devel] jack dsp load calculation

Robin Gareus
Hi all,

I'd like to propose changing the algorithm how jack calculates the DSP
load from averaging to worst-case.

The main reason for having DSP load is to know how much more processing
one can safely add without getting x-runs. What matters in this case is
the worst-case value.



It looks like there are some prior attempts in the code [1], but the
current averaging DSP load is pretty much useless for this. As-is, it
mainly lends itself to compare different machines.

Short spikes, which are in most cases the cause for xruns, are simply
ignored in the calculation: For them to show up, currently three
criteria must be met: The spike must be in the last 32 jack-cycles, be >
95% and the control application must read the value near the end of
those 32 cycles (see [1], very high LPF).

At 1024fpp / 48KHz, 32 cycles corresponds to ~680msec. Most control
applications only update the value every second or so.

Apart from that, I'm at a loss how to interpret the current value in a
meaningful way.


The proposed change is to:
 - jump to the worst-case value if it is larger than the current load
 - slow fall-off (1st order low-pass), 4-5 seconds (not cycle dependent)

I'm happy to submit a patch for this.

The only downside I can think of is that the reading will be higher and
some users will complain about this being a regression.

thoughts, comments?
robin


[1]
https://github.com/jackaudio/jack2/blob/master/common/JackEngineControl.cpp#L66

_______________________________________________
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

Paul Davis


On Wed, Dec 23, 2015 at 10:35 AM, Robin Gareus <[hidden email]> wrote:

Short spikes, which are in most cases the cause for xruns, are simply
ignored in the calculation: For them to show up, currently three
criteria must be met: The spike must be in the last 32 jack-cycles, be >
95% and the control application must read the value near the end of
those 32 cycles (see [1], very high LPF).

there is a justification for this. your paragraph starts with the claim that these short spikes correspond to xruns. there is a counter-claim that they represent measurement error.

i'm in full agreement with your argument *if* it can be shown that the spikes are not measurement errors (or, alternatively, that measurement error is best excluded via a different heuristic).
 

_______________________________________________
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 23 Dec 2015, at 15:35, Robin Gareus wrote:

> Hi all,
>
> I'd like to propose changing the algorithm how jack calculates the DSP
> load from averaging to worst-case.
>
> The main reason for having DSP load is to know how much more processing
> one can safely add without getting x-runs. What matters in this case is
> the worst-case value.
>

Matters to whom..?  As one of the people who implemented the current scheme, let me explain why it was needed...

We implemented the averaging mechanism when Harrison and I ported their Mixbus DAW to Windows.  Windows isn't a real-time OS and one of its drawbacks is that concurrently running apps can have an effect on each other.  Not necessarily a detrimental effect - but an effect nonetheless.

Before averaging, a concurrent (though unrelated) background app could have a very noticeable effect on Mixbus's DSP reading.  A nice reading of (say) 18% DSP could suddenly shoot up to 70% if the user ran some other process in the background.  70% was perfectly manageable - though pretty alarming for a user.  70% DSP for a simple session with only 1 track did nothing for customer confidence.

Currently, Jack DOES report the worst case value - IF - the worst case value is high enough to start causing problems (or if there's a sustained sequence of high values).  But if there's only an occasional high value (which is perfectly manageable) then it just gets factored into the current average.  The advantage of this approach is that Mixbus's DSP reading remains unaffected by other running apps.

The threshold we chose was 95%.  So if any value is 95% or higher, the highest value will always get reported.  There's an argument for saying that we possibly set the bar too high (at 95%) but I don't think there's anything else inherently wrong with the current strategy.

UNLESS - it's causing problems on the other platforms (in which case, there's an argument for keeping the averaging mechanism on Windows but removing it elsewhere).  Or unless (as Paul pointed out) it's introducing measurement errors.  Averaging is bound to introduce some kind of error - though I've never known it to be serious (on Windows, at least).

If people are getting xruns at DSP values lower than 95%, we perhaps just need to change the threshold.

Just my 2 cents...

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

Florian Paul Schmidt-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23.12.2015 21:20, John Emmas wrote:

[...]

Sidestepping from the discussion: Why not make more statistics
available. Or even better: Make the information to generate the
statistics available.

I.e. add a callback to provide measurements from the previous cycle.

Something like

jack_register_measurement_callback(void (f*)(jack_measurements*));

where jack_measurements is an opaque type with associated functions

uint64_t
jack_measurements_get_cycle_available_milliseconds(jack_measurements*);

uint64_t
jack_measurements_get_cycle_consumed_milliseconds(jack_measurements*);

where the former provides the available milliseconds for processing
the whole jack graph (maybe normalized by number of cpus (jack2) or
not (jack1)) and the latter provides the consumed milliseconds.

Units, function names, what measurements, etc, are subject to further
discussion, but this would allow different clients to provide the
statistics they need for their usecase.

Flo

- --
https://fps.io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWewieAAoJEA5f4Coltk8Z7pcH/RLB1tmFlYFLQaZPLJ4tnxIA
nQQTxzoAksqWiPzAqS31tg9uQC5XMratjaLMSXGd9yDBg+2Jt3a6zvuwvAH21EuD
Y5PNh+vPhtvyZXs/q+p0lOWta9v3VR7OZ85GKn3KGE8jeSfs2eRCDQ4TW/jhMz9i
/ZdvvKQv2kzEDoQ/0/evfG2ttJXzEVPZ+j+FZGlSJEo4LtJXhqltOwoM/xv/u6f9
hQPLEFPbf+zaeIhJIdCabp1GfXJWNqydzu5uecMfgw47Or8utnxK6HXKHOKg/Max
AXCXeFsmAGcpVkrlLTqst9TYYbuKFld4+azxnkbq/3WcRup80SojtcBtkQnrWIU=
=XhKy
-----END PGP SIGNATURE-----
_______________________________________________
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
Something occurred to me while tucking into my breakfast this morning...

On 23/12/2015 15:35, Robin Gareus wrote:
> Short spikes, which are in most cases the cause for xruns, are simply
> ignored in the calculation: For them to show up [...] the spike must
> be in the last 32 jack-cycles. [...] Most control applications only
> update the value every second or so.
>

Of course!  If users are hearing xruns without them showing up in the
DSP figure, this must be where the problem lies.  And it won't get
solved by changing the calculation algorithm.  Removing the averaging
would simply introduce a new set of problems without addressing the
underlying issue (i.e. that the client is updating too infrequently).

I wondered if Jack might have any other means of notifying a client when
an xrun occurs?  (i.e. apart from returning a load count of 100)?  Let's
say that clients (Ardour/Mixbus or whatever) could get notified about
xruns using a callback function.  There'd then be a simple solution.  
Instead of just querying the DSP reading once every second, clients
could use a strategy like this (which would still work - even if only
used once every second):-

       if ( the_client->got_notified_about_an_xrun() ) {
             //  We know that an xrun occurred since we last checked
             //  the CPU load - so do something to accommodate that.

             //  and then reset the notification flag
             reset_the_xrun_notification_flag ();
       } else {
             //  No xrun was encountered - so we can update normally...
             update_cpu_load ();
       }

Is there anything like that already available.?

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

Hanspeter Portner
On 26.12.2015 10:38, John Emmas wrote:

> Something occurred to me while tucking into my breakfast this morning...
>
> On 23/12/2015 15:35, Robin Gareus wrote:
>> Short spikes, which are in most cases the cause for xruns, are simply
>> ignored in the calculation: For them to show up [...] the spike must
>> be in the last 32 jack-cycles. [...] Most control applications only
>> update the value every second or so.
>>
>
> Of course!  If users are hearing xruns without them showing up in the
> DSP figure, this must be where the problem lies.  And it won't get
> solved by changing the calculation algorithm.  Removing the averaging
> would simply introduce a new set of problems without addressing the
> underlying issue (i.e. that the client is updating too infrequently).
>
> I wondered if Jack might have any other means of notifying a client when
> an xrun occurs?  (i.e. apart from returning a load count of 100)?  Let's
> say that clients (Ardour/Mixbus or whatever) could get notified about
> xruns using a callback function.  There'd then be a simple solution.
> Instead of just querying the DSP reading once every second, clients
> could use a strategy like this (which would still work - even if only
> used once every second):-
>
>       if ( the_client->got_notified_about_an_xrun() ) {
>             //  We know that an xrun occurred since we last checked
>             //  the CPU load - so do something to accommodate that.
>
>             //  and then reset the notification flag
>             reset_the_xrun_notification_flag ();
>       } else {
>             //  No xrun was encountered - so we can update normally...
>             update_cpu_load ();
>       }
>
> Is there anything like that already available.?

Sure, that's what 'jack_set_xrun_callback' [1] is for.

[1]
http://jackaudio.org/api/group__ClientCallbacks.html#ga08196c75f06d9e68f9a3570dfcb1e323

_______________________________________________
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 Paul Davis
On 12/23/2015 08:29 PM, Paul Davis wrote:

> On Wed, Dec 23, 2015 at 10:35 AM, Robin Gareus <[hidden email]> wrote:
>
>>
>> Short spikes, which are in most cases the cause for xruns, are simply
>> ignored in the calculation: For them to show up, currently three
>> criteria must be met: The spike must be in the last 32 jack-cycles, be >
>> 95% and the control application must read the value near the end of
>> those 32 cycles (see [1], very high LPF).
>>
>
> there is a justification for this. your paragraph starts with the claim
> that these short spikes correspond to xruns. there is a counter-claim that
> they represent measurement error.
>
> i'm in full agreement with your argument *if* it can be shown that the
> spikes are not measurement errors

If jack can't keep track of the time properly we have much more serious
issues.

jackd on POSIX systems is robust. The time is queried in a high priority
thread and jack2 offers `--clocksource` for a user to tweak it if needed.

> (or, alternatively, that measurement
> error is best excluded via a different heuristic).

Yes, outliers - e.g jumps on suspend/resume or leap-seconds
(non-monotonic clock) must be skipped.

In Ardour we ended up ignoring negative deltas and jumps larger than 10
times the cycle-length. (This in particular is relevant for AMD machines
and Windows XP where the clock is per cpu-core.)

Early 4.X had a sigma-cut (based on running variance) but that turned
out too be too statistical for the case of displaying peak-computing power.

so long,
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

Robin Gareus
In reply to this post by John Emmas
On 12/23/2015 09:20 PM, John Emmas wrote:

> On 23 Dec 2015, at 15:35, Robin Gareus wrote:
>
>> Hi all,
>>
>> I'd like to propose changing the algorithm how jack calculates the DSP
>> load from averaging to worst-case.
>>
>> The main reason for having DSP load is to know how much more processing
>> one can safely add without getting x-runs. What matters in this case is
>> the worst-case value.
>>
>
> Matters to whom..?  

Those who want to know the peak DSP load and available headroom.

The average is meaningless in the context of DSP. A system may run
without x-runs 99% of the time but then some NMI or SMI comes along and
ruins it all. Nobody cares if the average is below 50%.

> As one of the people who implemented the current scheme, let me
> explain why it was needed...
>
> We implemented the averaging mechanism when Harrison and I ported
> their Mixbus DAW to Windows.  Windows isn't a real-time OS and one of
> its drawbacks is that concurrently running apps can have an effect on
> each other.  Not necessarily a detrimental effect - but an effect
> nonetheless.

It's Mixbus that motivated me to looking into this, actually.  There are
forum reports: "DSP load is 40% and there are x-runs".

> Before averaging, a concurrent (though unrelated) background app
> could have a very noticeable effect on Mixbus's DSP reading.  A nice
> reading of (say) 18% DSP could suddenly shoot up to 70% if the user
> ran some other process in the background.  70% was perfectly
> manageable - though pretty alarming for a user.

and rightfully so, what do we gain by hiding this?

If a user starts another application and that app steals time from
jack's realtime callback, that's what it is.

If there are regular spikes (quite common on windows), those spikes do
interfere with processing.

In your example, if the initial DSP load was 48%, it'll go over 100%
when the user starts something in the background.

This is the precise case that we're seeing currently: A user adds some
3rd part DSP. The load stays below 50% but there are regular
dropouts/crackles and only sometimes the DSP indicator goes "red" (> 95%
in Mixbus) with jack.

Ardour's port-audio backend reports the peak and is always > 90% in that
case. So the user switched to JACK because "jack has half the DSP load",
and the crackles are still there...


> Currently, Jack DOES report the worst case value - IF - the worst
> case value is high enough to start causing problems (or if there's a
> sustained sequence of high values).

No it does not. If that was the intent, it's an oversight or bug in the
current implementation. Two very unlikely conditions must coincide, and
there is always a low-pass filter at the end.

> But if there's only an occasional high value (which is perfectly
> manageable) then it just gets factored into the current average.

How can an occasional high value be perfectly manageable?

> The advantage of this approach is that Mixbus's DSP reading remains unaffected by other running apps.

I see this as a disadvantage. Those other apps may affect audio-i/o and
cause spikes.

> The threshold we chose was 95%.  So if any value is 95% or higher, the highest value will always get reported.

What you describe does not match the current code in jack2.

Still the larger issue is the report-time. The peak is only held for 32
jack-cycles. It's worse since the final LPF ramps up and down and the
actual value. The report-time of the peak is commonly below 100ms.  That
is a very short time for any report to be interpreted by a human.


> There's an argument for saying that we possibly set the bar too high
> (at 95%) but I don't think there's anything else inherently wrong
> with the current strategy.


The 95% cut is done before filtering and overrides other bins in the
history. I understand that parts of the strategy was to work around
issues with unreliable clocks on non-realtime OS - in particular
windows, but I think the situation can be improved.

My main criticism is that it's some homebrew statistics with no real
meaning. I don't know how to interpret the readout, nor see it useful
as-is, except maybe for marketing or for comparing machines against each
other or maybe even compete with other DSP software ("ours is lower on
average").

> If people are getting xruns at DSP values lower than 95%, we perhaps just need to change the threshold.

How will that help?

One could argue that we may want two numbers: a true average and a peak
(maybe even user-resettable), although a slow fall-off is probably
preferable because there is already an independent x-run counter.

2c,
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

Kjetil Matheussen-2


On Sat, Dec 26, 2015 at 1:56 PM, Robin Gareus <[hidden email]> wrote:
On 12/23/2015 09:20 PM, John Emmas wrote:
> On 23 Dec 2015, at 15:35, Robin Gareus wrote:
>
>> Hi all,
>>
>> I'd like to propose changing the algorithm how jack calculates the DSP
>> load from averaging to worst-case.
>>
>> The main reason for having DSP load is to know how much more processing
>> one can safely add without getting x-runs. What matters in this case is
>> the worst-case value.
>>
>
> Matters to whom..?

Those who want to know the peak DSP load and available headroom.

The average is meaningless in the context of DSP. A system may run
without x-runs 99% of the time but then some NMI or SMI comes along and
ruins it all. Nobody cares if the average is below 50%.


For what it's worth, Radium reports three values: 1. Minimum CPU measured
for a block during the last second, 2. Average CPU usage during the last second,
3. Maximum CPU usage measured for a block during the last second

All three values are useful, at least for me as a developer of the program,
but I guess the users might find all three values interesting as well. At least
the user doesn't have to wonder whether it's showing peak or average
values, and what the average/peak values would have been if only one
of them had been shown. I guess peak value is the most useful value,
but by showing average and minimum as well, we also indicate the potential
performance the program can deliver without xruns. This potential
can be used by the user to close other programs and do other operations
that might make the computer perform better.

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.




_______________________________________________
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 02:33 PM, Kjetil Matheussen wrote:

> On Sat, Dec 26, 2015 at 1:56 PM, Robin Gareus <[hidden email]> wrote:
>
>> On 12/23/2015 09:20 PM, John Emmas wrote:
>>> On 23 Dec 2015, at 15:35, Robin Gareus wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'd like to propose changing the algorithm how jack calculates the DSP
>>>> load from averaging to worst-case.
>>>>
>>>> The main reason for having DSP load is to know how much more processing
>>>> one can safely add without getting x-runs. What matters in this case is
>>>> the worst-case value.
>>>>
>>>
>>> Matters to whom..?
>>
>> Those who want to know the peak DSP load and available headroom.
>>
>> The average is meaningless in the context of DSP. A system may run
>> without x-runs 99% of the time but then some NMI or SMI comes along and
>> ruins it all. Nobody cares if the average is below 50%.
>>
>>
> For what it's worth, Radium reports three values: 1. Minimum CPU measured
> for a block during the last second, 2. Average CPU usage during the last
> second,
> 3. Maximum CPU usage measured for a block during the last second
> ( http://folk.uio.no/ksvalast/radiumcpu.png )

nice.

That is per application, right?  Not the whole system - jack can include
other clients.

> All three values are useful, at least for me as a developer of the program,
> but I guess the users might find all three values interesting as well.

For end users in Mixbus  we are considering to maybe even "dumb it
down": A simple light: green/yellow/red or a short e.g 6-LED peak-meter.

The motivation here: don't encourage comparing percent values.

However it must be meaningful to answer
 1) can I safely add more plugins?
 2) can I lower the period-size or is the current cycle already very
short for my setup?

> At least
> the user doesn't have to wonder whether it's showing peak or average
> values, and what the average/peak values would have been if only one
> of them had been shown. I guess peak value is the most useful value,
> but by showing average and minimum as well, we also indicate the potential
> performance the program can deliver without xruns. This potential
> can be used by the user to close other programs and do other operations
> that might make the computer perform better.
>
> 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.

On which platform is that? with JACK?

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
In reply to this post by Robin Gareus
On 26/12/2015 12:56, Robin Gareus wrote:
> It's Mixbus that motivated me to looking into this, actually.  There are
> forum reports: "DSP load is 40% and there are x-runs".
>

That's true - but are they happening with the Jack backend?

When you and Tim first implemented your PortAudio backend (the blocking
version) I regularly heard xruns at only 40% DSP.  But I don't see how
you can blame them on Jack.  When running with a Jack backend I've (very
occasionally) encountered xruns at around 92% DSP (which is why my first
suggestion was to lower the threshold). However, I think my later
suggestion is better (to factor in any xruns which occurred between the
previous reading and the new one).

I'm sorry to be rude Robin but I don't think your suggestion has got
anything to do with improving Jack.  I suspect you're trying to degrade
Jack's figures to make them match the ones from your PortAudio backend
(which are generally poorer).  Mixbus has been on sale for years.  Sales
run into thousands - but I can't remember a single complaint about xruns
happening at such low DSP loads (prior to your PortAudio backend coming
along).

If the new backend suffers from xrun problems, fix them.  But don't fix
them by trying to nobble the other backends.  If Jack was suffering from
the problem you described above, we'd have all heard about it a long
time before now.  MB has at least 5 years of sales behind it.  So how
come we only started noticing this problem in the past few months?

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 03:07 PM, John Emmas wrote:

> If the new backend suffers from xrun problems, fix them.

It does not. It's pretty much equivalent to JACK (and actually a tad
better in some cases).

Please read my email again.

There are cases when there *are* xruns, while jack wrongly reports a DSP
usage of < 50% while it fact it peaks over 100%.

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 26/12/2015 14:16, Robin Gareus wrote:
> There are cases when there *are* xruns, while jack wrongly reports a DSP
> usage of < 50% while it fact it peaks over 100%.
>

I very much doubt that.

The top-level application might be reporting < 50% (if it isn't querying
Jack often enough).  And I think you've made a very good case for that.  
But you haven't produced any evidence to suggest that Jack itself is
missing the xruns.  What's needed is to make sure that the app will
notice them if they occur (in between update calls).  Removing the
averaging isn't the way to achieve that.  I know that's what you've done
in the PortAudio backend - but it's not the right approach.

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 03:34 PM, John Emmas wrote:

> On 26/12/2015 14:16, Robin Gareus wrote:
>> There are cases when there *are* xruns, while jack wrongly reports a DSP
>> usage of < 50% while it fact it peaks over 100%.
>>
>
> I very much doubt that.
>
> The top-level application might be reporting < 50% (if it isn't querying
> Jack often enough).  And I think you've made a very good case for that.
> But you haven't produced any evidence to suggest that Jack itself is
> missing the xruns.

This part is correct. The x-run counter increases correctly.

> What's needed is to make sure that the app will
> notice them if they occur (in between update calls).  Removing the
> averaging isn't the way to achieve that.  I know that's what you've done
> in the PortAudio backend - but it's not the right approach.

I think we're talking cross-purpose.

Effectively it boils down to this: Is the reported DSP load supposed to
be "average" or "worst-case" or a "hybrid" (current implementation)?

I like Nedko's idea: Allow to query all: min, average, max  over a long
time compared to the process-cycle (think second or seconds).

That leaves it to the application which of those are displayed to the
user, but at least the mechanism in the underlying infrastructure (here
jack) is well defined.

2c,
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/12/2015 14:41, Robin Gareus wrote:
> I like Nedko's idea: Allow to query all: min, average, max  over a long
> time compared to the process-cycle (think second or seconds).
>

Hmm...  I didn't get that email for some reason.  But yes - as a feature
update, that sounds promising.  I'm just pointing out that (a) the
averaging mechanism / hybrid approach is NOT the underlying cause of the
problem you described - and (b) in Mixbus and Ardour, we can already
make a solution which wouldn't need us to tinker with Jack.  i.e. the
following strategy instead of our current one:-

       if ( the_client->got_notified_about_an_xrun() ) {
             //  We know that an xrun occurred since we last checked
             //  the CPU load - so do something to accommodate that.

             //  and then reset the notification flag
             reset_the_xrun_notification_flag ();
       } else {
             //  No xrun was encountered - so we can update normally...
             update_cpu_load ();
       }

That would be very simple to implement and I honestly think we should
try that first, before tinkering too much with 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/26/2015 04:10 PM, John Emmas wrote:

> On 26/12/2015 14:41, Robin Gareus wrote:
>> I like Nedko's idea: Allow to query all: min, average, max  over a long
>> time compared to the process-cycle (think second or seconds).
>>
>
> Hmm...  I didn't get that email for some reason.  But yes - as a feature
> update, that sounds promising.  I'm just pointing out that (a) the
> averaging mechanism / hybrid approach is NOT the underlying cause of the
> problem you described - and (b) in Mixbus and Ardour, we can already
> make a solution which wouldn't need us to tinker with Jack.  i.e. the
> following strategy instead of our current one:-
>
>       if ( the_client->got_notified_about_an_xrun() ) {
>             //  We know that an xrun occurred since we last checked
>             //  the CPU load - so do something to accommodate that.

Why are x-runs (100% usage not) included in the statistics?

>             //  and then reset the notification flag
>             reset_the_xrun_notification_flag ();
>       } else {
>             //  No xrun was encountered - so we can update normally...
>             update_cpu_load ();

What does "update_cpu_load ();" do?

>       }
>
> That would be very simple to implement and I honestly think we should
> try that first, before tinkering too much with Jack.

Ardour/Mixbus has an explicit x-run counter since April 2015. Except the
x-run counter is user-resettable (in the toolbar). But the problem goes
back further. We've been pushing it off because it's mainly a detail and
I expected longer discussions...


My criticism is that jack's currently algorithm does not satisfy the
criteria: "an x-run implies 100% reported load".

How can we justify buffer over/under-runs if there is time left to
process the buffer?

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

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


On Sat, Dec 26, 2015 at 3:04 PM, Robin Gareus <[hidden email]> wrote:
> For what it's worth, Radium reports three values: 1. Minimum CPU measured
> for a block during the last second, 2. Average CPU usage during the last
> second,
> 3. Maximum CPU usage measured for a block during the last second
> ( http://folk.uio.no/ksvalast/radiumcpu.png )

nice.

That is per application, right?  Not the whole system - jack can include
other clients.


Yes, this is just local CPU measures. No jack calls.
 

> All three values are useful, at least for me as a developer of the program,
> but I guess the users might find all three values interesting as well.

For end users in Mixbus  we are considering to maybe even "dumb it
down": A simple light: green/yellow/red or a short e.g 6-LED peak-meter.

The motivation here: don't encourage comparing percent values.

However it must be meaningful to answer
 1) can I safely add more plugins?
 2) can I lower the period-size or is the current cycle already very
short for my setup?


Guess it could be complicated to do that without showing accurate values to the user.
As a user, I would also wonder why I am not allowed to see percentages.



> 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.

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.


_______________________________________________
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 15:38, Robin Gareus wrote:

>
> My criticism is that jack's currently algorithm does not satisfy the
> criteria: "an x-run implies 100% reported load".
>
> How can we justify buffer over/under-runs if there is time left to
> process the buffer?
>

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?

The problem here is that Ardour's DSP printout is NOT intended to highlight xruns (not in any sense).  It's simply a display (in green) which turns to red when the value gets worryingly high.

BUT... it only gets updated once every second.  And since the display isn't (currently) affected in any way by xruns, if an xrun happens to occur in between 2 updates it can go unreported (as far as that DSP reading is concerned).  Removing Jack's averaging won't fix that problem.

HOWEVER... Ardour already has a mechanism for registering xruns.  So if we want xruns to get reflected somehow in that DSP printout, we can already achieve that within Ardour.  It's not necessary to modify 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
In reply to this post by Kjetil Matheussen-2
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?

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

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

Robin Gareus
In reply to this post by John Emmas
On 12/26/2015 05:27 PM, John Emmas wrote:

> On 26 Dec 2015, at 15:38, Robin Gareus wrote:
>
>>
>> My criticism is that jack's currently algorithm does not satisfy the
>> criteria: "an x-run implies 100% reported load".
>>
>> How can we justify buffer over/under-runs if there is time left to
>> process the buffer?
>>
>
> 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?

This is not true. There is always a low-pass filter after the cut and
averaging. Please read my email again and maybe also the code that've
linked in the original email.

> The problem here is that Ardour's DSP printout is NOT intended to
> highlight xruns (not in any sense). It's simply a display (in green)
> which turns to red when the value gets worryingly high.

No, The problem at hand is that *JACK* reports some mostly useless value.

If you want a more abstract description: Two correlated variables are
used to create a single read-out.

The discussion is about jack's mechanism - not the policy applied by
application display.

I was under the impression that jack only provides mechanisms. The
current implementation of the load calculation in libjack however does
make assumptions and does not provide raw data (which an application can
then later use to whatever ends..)

> BUT... it only gets updated once every second. And since the display
> isn't (currently) affected in any way by xruns, if an xrun happens to
> occur in between 2 updates it can go unreported (as far as that DSP
> reading is concerned). Removing Jack's averaging won't fix that problem.
>
> HOWEVER... Ardour already has a mechanism for registering xruns. So
> if we want xruns to get reflected somehow in that DSP printout, we can
> already achieve that within Ardour. It's not necessary to modify Jack.

No we cannot. jack currently does not provide data to allow that. it
reports some tainted average value.

I still have not heard a good justification for libjack doing that, nor
an explanation how to interpret that value and how one can use it.

Why should jack report a percentage if we need to resort to hand-wavey
explanations: "yeah the average is low, but you still get occasional
x-runs..."?

if there's an average we should provide a variance or stddev with the
average.

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