29 Apr
2010
29 Apr
'10
3:12 p.m.
On Thu, Apr 29, 2010 at 5:02 AM, michael noble <looplog(a)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