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

michael noble looplog at gmail.com
Thu Apr 29 05:58:49 UTC 2010


On Thu, Apr 29, 2010 at 12:41 PM, Paul Davis <paul at linuxaudiosystems.com>wrote:

> this is not the diagram that people are referring to. latency is an issue
> when you have:
>    A/D -> Ardour -> Rakarrack -> Ardour -> D/A

yes, I understood Tim was referring to a send/return loop. I actually didn't
realise there would be a difference in latency between a linear or looped
signal flow.

> its not a pointless exercise in frustration because this kind of
> connectivity (A feeds B which feeds A) is useful but not as common as the
> more simple (A feeds B feeds C).

OK, but what kind of modularity is it that puts a heavy penalty on
non-linear signal flows? I thought, after all, that JACK was designed
explicitly to be suited to real-time, or as close as possible to RT, modular
audio routing.

> there have been some suggestions to allow/encourage applications to have
> multiple clients precisely to permit the A->B->A ("insert") processing to
> work with no extra latency.

Now I'm more confused. You seem to be saying without actually saying that
JACK basically adds latency in any signal loop, but not in a linear chain?
Is that correct? This seems very odd to me, though I admit I don't know the
first thing of the technical justifications for it being so. I had naively
assumed JACK was just passing signals between clients regardless of the
clients' position in the chain.

Are the input and output stages of jack clients coupled in some way that
makes this so?

Again in my naive fashion (and I'm not being sarcastic here) I don't
understand the difference between the following three graphs:

A/D -> Ardour -> Rakarrack -> Ardour -> D/A


A/D -> [jack client input -> jack client out] -> [jack client input -> jack
client out] -> [jack client input -> jack client out] -> D/A


A/D -> PD -> Rakarrack -> Ardour -> D/A


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

More information about the Linux-audio-dev mailing list