[LAD] JACK Graph Internal Latency? (was Re: A small article ...)

[Tim E. Real]

On April 28, 2010 10:45:28 pm you wrote:
> hi all,
>
> On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech at rogers.com> wrote:
> > Just a request: Would be awesome as a DSSI plugin so that we
> >  don't have to use rakarrack in a 'send and return' loop within our apps,
> >  which causes latency due to the round trip...
> > Tim.
>
> This raises a question that I've had for a while regarding latency in the
> JACK graph. I may have even asked it in the past, but if I did I either
> wasn't satisfied with the answer or have forgotten it completely. Either
> way, I'm unable to find it in the archives.
>
> My understanding is that connections between applications in the JACK graph
> should add absolutely no additional latency to the signal path. Latency is
> of course introduced at the A/D and D/A conversion stage of the graph,
> which is to be expected. This is the latency figure that jack reports - the
> latency introduced at every A/D or D/A stage. 
> The only additional latency
> introduced is by processing internal to any applications, for example by
> the use of sample blocks as in the case of convolution.
>
> Am I correct in this? If so, then I don't understand Tim's statement above,
> as there should be no difference, in terms of latency, between using
> Rakarrack as a plugin (if it were possible) within an application, or
> placing it in an external send/return loop in the JACK graph.
>
> If my assumption is not correct, then I'm actually highly confused as to
> what the value of JACK is at all. If latency were introduced at every
> additional JACK signal routing, then even a simple routing like the
> following:
>
> A/D -> Rakarrack -> Jackrack -> Ardour -> D/A
>
> would have no less than four multiples of the internal JACK latency. This
> would quickly become unworkable in more complex JACK graphs (for example
> asymmetrical graphs would have signal chains running with different
> internal latencies). This would make having application interconnects a
> pointless exercise in frustration for the most part. And actually, from
> experience, this is not what seems to happen at all.
>
> Feel free to correct my admittedly limited technical understand of how
> latency is handled internally to the JACK graph...
>
> -michael
Maybe I made a mistake there, confusing a plugin chain with analog latencies. 
Ah but then, isn't a plugin chain like a 'bucket brigade'?
Each stage can't know what the previous stage does to the signal until
 that previous stage has processed a whole buffer.
("He said, waiting to be clobbered by the responses.")

Tim.