Re: [Jack-Devel] jack dsp load calculation

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

1451153701.1228_0.ltw:2,a <567ED91C.1090108 at gareus dot org>