Re: [Jack-Devel] jack dsp load calculation

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

1451222035.4534_0.ltw:2,a <638B1023-6715-4CE9-BCEF-503A2C9D7F6C at tiscali dot co dot uk>