[LAD] JACK Graph Internal Latency? (was Re: A small article ...)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Tim E. Real <termtech@...>
Cc: <linux-audio-dev@...>
Date: Thursday, April 29, 2010 - 2:45 am

--0016363b7d8693df330485571eff
Content-Type: text/plain; charset=ISO-8859-1

hi all,

On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real wrote:

>

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

--0016363b7d8693df330485571eff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi all,On Thu, Apr 29, 2010 at 7:05 AM, =
Tim E. Real <te=
rmtech@rogers.com
> wrote:

Just a request: Would be awesome as a DSSI plugin so that we
=A0don't have to use rakarrack in a 'send and return' loop with=
in our apps,
=A0which causes latency due to the round trip...
Tim.
This raises a question that I&=
#39;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 g=
raph should add absolutely no additional latency to the signal path. Latenc=
y 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 - th=
e 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 t=
he use of sample blocks as in the case of convolution.
Am I correct in this? If so, then I don't understand Tim's stat=
ement above, as there should be no difference, in terms of latency, between=
using Rakarrack as a plugin (if it were possible) within an application, o=
r 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 follow=
ing:
A/D -> Rakarrack -> Jackrack -> Ardour -> D/Awould =
have no less than four multiples of the internal JACK latency. This would q=
uickly become unworkable in more complex JACK graphs (for example asymmetri=
cal graphs would have signal chains running with different internal latenci=
es). This would make having application interconnects a pointless exercise =
in frustration for the most part. And actually, from experience, this is no=
t 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

--0016363b7d8693df330485571eff--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] JACK Graph Internal Latency? (was Re: A small article ..., michael noble, (Thu Apr 29, 2:45 am)
Re: [LAD] , Rui Nuno Capela, (Thu Apr 29, 10:41 am)
Re: [LAD] , Rui Nuno Capela, (Thu Apr 29, 1:49 pm)