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

Paul Davis paul at linuxaudiosystems.com
Thu Apr 29 13:12:26 UTC 2010


On Thu, Apr 29, 2010 at 5:02 AM, michael noble <looplog at gmail.com> wrote:

> So ok, I was able to confirm by having someone try it out for me (not on my
> linux machine right now) that Tim and of course Paul, you are both correct
> in that a JACK client in a send/return loop adds additional latency. So now
> I'm left with the obvious question of "why?".
>

Rui has already basically answered this, but I'll repeat. Every client in
the graph is only executed *once* per process cycle. Hence, given

      A -> B -> A

any given process cycle only executes A once. thus the output of B is not
available to A until the next process cycle.

This is true of ANY block-structured audio graph (as opposed to
single-sample designs). It applies to plugins too, but people do not often
create looped signal flow involving a plugin. An example might help though:
a side-chain compressor whose side-chain input comes from a gate plugin that
is after itself:

   ->  SC-comp -> Gate ->
         ^                    v
         |                     |
         +---------------+

in this example, just the like one above, the output of Gate is not
available to SC-comp until the NEXT time SC-comp is executed.

to repeat: JACK is not unusual in this respect. if you want to avoid this
kind of effect of a feedback loop, you have to use single sample processing,
which is not practical on general purpose computing hardware at this time.

--p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100429/b6eed83f/attachment.html>


More information about the Linux-audio-dev mailing list