hey,

On Thu, Apr 29, 2010 at 12:41 PM, Paul Davis <paul@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

and

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

and

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

regards

Michael