Just a request: Would be awesome as a DSSI plugin so that we
don't have to use rakarrack in a 'send and return' loop within our apps,
which causes latency due to the round trip...
Tim.
This raises a question that I've had for a while regarding latency in the JACK graph. I may have even asked it in the past, but if I did I either wasn't satisfied with the answer or have forgotten it completely. Either way, I'm unable to find it in the archives.
My understanding is that connections between applications in the JACK graph should add absolutely no additional latency to the signal path. Latency is of course introduced at the A/D and D/A conversion stage of the graph, which is to be expected. This is the latency figure that jack reports - the latency introduced at every A/D or D/A stage. The only additional latency introduced is by processing internal to any applications, for example by the use of sample blocks as in the case of convolution.
Am I correct in this? If so, then I don't understand Tim's statement above, as there should be no difference, in terms of latency, between using Rakarrack as a plugin (if it were possible) within an application, or placing it in an external send/return loop in the JACK graph.
If my assumption is not correct, then I'm actually highly confused as to what the value of JACK is at all. If latency were introduced at every additional JACK signal routing, then even a simple routing like the following:
A/D -> Rakarrack -> Jackrack -> Ardour -> D/A
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.
Feel free to correct my admittedly limited technical understand of how latency is handled internally to the JACK graph...