<br><br><div class="gmail_quote">On Thu, Apr 29, 2010 at 5:02 AM, michael noble <span dir="ltr"><<a href="mailto:looplog@gmail.com">looplog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?".<br>
</blockquote><div><br>Rui has already basically answered this, but I'll repeat. Every client in the graph is only executed *once* per process cycle. Hence, given<br><br>      A -> B -> A<br><br>any given process cycle only executes A once. thus the output of B is not available to A until the next process cycle.<br>
<br>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:<br>
  <br>   ->  SC-comp -> Gate -><br>         ^                    v<br>         |                     |<br>         +---------------+<br><br>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.<br>
<br>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.<br>
<br>--p<br><br><br></div></div>