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

[Tim E. Real]

On April 29, 2010 12:39:30 am Tim E. Real wrote:
> 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.")
Oops, yeah that happens, but all within one process cycle.
Each plugin in the chain is run in succession on the data, right?
My mistake. Must be tired, the ol' brain wanders... 

>
> Tim.
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev