<br><br><div class="gmail_quote">On Wed, Apr 28, 2010 at 10:45 PM, 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;">
<br>
<br>A/D -> Rakarrack -> Jackrack -> Ardour -> D/A<br></blockquote><div><br>this is not the diagram that people are referring to. latency is an issue when you have:<br><br>   A/D -> Ardour -> Rakarrack -> Ardour -> D/A<br>
 <br>i.e. Rakarrack as an insert for an ardour track or bus.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">would have no less than four multiples of the internal JACK latency. This would quickly become unworkable in more complex JACK graphs (for example asymmetrical graphs would have signal chains running with different internal latencies). This would make having application interconnects a pointless exercise in frustration for the most part. And actually, from experience, this is not what seems to happen at all.<br>
</blockquote><div><br>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). <br><br>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. <br>
</div></div>