On April 28, 2010 10:45:28 pm you wrote: > hi all, > > On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <[email protected]> wrote: > > 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... > > -michael Maybe I made a mistake there, confusing a plugin chain with analog latencies. Ah but then, isn't a plugin chain like a 'bucket brigade'? Each stage can't know what the previous stage does to the signal until that previous stage has processed a whole buffer. ("He said, waiting to be clobbered by the responses.")
Tim. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
