On Thu, Apr 29, 2010 at 5:02 AM, michael noble <looplog@email-addr-hidden> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Apr 29 20:15:05 2010
This archive was generated by hypermail 2.1.8 : Thu Apr 29 2010 - 20:15:06 EEST