<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 6:52 PM, Tim Goetze <span dir="ltr"><<a href="mailto:tim@quitte.de" target="_blank">tim@quitte.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":1gf">If you're not doing anything funky (and you'd have to go out of your<br>
way to)</div></blockquote></div><br>My understanding is that the latency measure displayed by JACK is for one cycle of the entire JACK graph (or something like that). That means apps in a standard linear signal chain won't add extra latency. It also means you don't have to be that funky to add extra latency - just put a loop anywhere in your signal chain (eg. a send from Ardour to an external jack app and back into Ardour). The audio won't be processed by the client at the loop point until the next execution cycle, effectively adding a full cycle of latency at that point in the signal chain. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>At least, that's how I think it was patiently explained to me a while back. </div></div>