Re: [Jack-Devel] jack dsp load calculation

PrevNext  Index
DateSat, 26 Dec 2015 22:56:43 +0100
From Joakim Hernberg <[hidden] at alchemy dot lu>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToRobin Gareus Re: [Jack-Devel] jack dsp load calculation
Follow-UpJoakim Hernberg Re: [Jack-Devel] jack dsp load calculation
Follow-UpRobin Gareus Re: [Jack-Devel] jack dsp load calculation
On Sat, 26 Dec 2015 19:14:52 +0100
Robin Gareus <[hidden]> 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
PrevNext  Index

1451167386.13765_0.ltw:2,a <20151226225643.144ef61c at balder dot valhalla dot alchemy dot lu>