29 Apr
2010
29 Apr
'10
4:45 a.m.
hi all,
On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech(a)rogers.com> 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
29 Apr
29 Apr
5:41 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Wed, Apr 28, 2010 at 10:45 PM, michael noble <looplog(a)gmail.com> wrote:
A/D -> Rakarrack -> Jackrack -> Ardour -> D/A
this is not the diagram that people are referring to. latency is an issue
when you have:
A/D -> Ardour -> Rakarrack -> Ardour -> D/A
i.e. Rakarrack as an insert for an ardour track or bus.
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.
its not a pointless exercise in frustration because this kind of
connectivity (A feeds B which feeds A) is useful but not as common as the
more simple (A feeds B feeds C).
there have been some suggestions to allow/encourage applications to have
multiple clients precisely to permit the A->B->A ("insert") processing to
work with no extra latency.
7:58 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
hey,
On Thu, Apr 29, 2010 at 12:41 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
this is not the diagram that people are referring to. latency is an issue
when you have:
A/D -> Ardour -> Rakarrack -> Ardour -> D/A
yes, I understood Tim was referring to a send/return loop. I actually didn't
realise there would be a difference in latency between a linear or looped
signal flow.
its not a pointless exercise in frustration because
this kind of
connectivity (A feeds B which feeds A) is useful but not as common as the
more simple (A feeds B feeds C).
OK, but what kind of modularity is it that puts a heavy penalty on
non-linear signal flows? I thought, after all, that JACK was designed
explicitly to be suited to real-time, or as close as possible to RT, modular
audio routing.
there have been some suggestions to allow/encourage applications to have
multiple clients precisely to permit the A->B->A ("insert") processing
to
work with no extra latency.
Now I'm more confused. You seem to be saying without actually saying that
JACK basically adds latency in any signal loop, but not in a linear chain?
Is that correct? This seems very odd to me, though I admit I don't know the
first thing of the technical justifications for it being so. I had naively
assumed JACK was just passing signals between clients regardless of the
clients' position in the chain.
Are the input and output stages of jack clients coupled in some way that
makes this so?
Again in my naive fashion (and I'm not being sarcastic here) I don't
understand the difference between the following three graphs:
A/D -> Ardour -> Rakarrack -> Ardour -> D/A
and
A/D -> [jack client input -> jack client out] -> [jack client input -> jack
client out] -> [jack client input -> jack client out] -> D/A
and
A/D -> PD -> Rakarrack -> Ardour -> D/A
regards
Michael
11:02 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
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?".
What is the difference, in terms of latency, between the following signal
chains in JACK?:
1) A/D -> A -> B -> A -> D/A
and
2) A/D -> A[B as plugin] -> -> D/A
and
3) A/D -> A -> B -> C -> D/A
Why is there additional latency added to client B in 1) but not 3),
especially in the case where C could be another instance of A?
And also, could the following section the JACK faq perhaps be altered to
provide some clarification here:
Doesn't use JACK add latency?
There is *NO* extra latency caused by using JACK for audio input and
output. When we say none, we mean absolutely zero. The only impact of using
JACK is a slight increase in the amount of work done by the CPU to process a
given chunk of audio, which means that in theory you could not get 100% of
the processing power that you might get it if your application(s) used ALSA
or CoreAudio directly. However, given that the difference is less than 1%,
and that your system will be unstable before you get close to 80% of the
theoretical processing power, the effect is completely disregardable.
I understand that this explicitly says "using JACK for audio input and
output", but the question itself is a little broader than that. To me it
implies that the entire JACK graph adds no additional latency. If I can be
pointed to a clarified explanation of the matter I'd happily provide some
documentation if no one else has the time or inclination.
regards
michael
11:17 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
michael noble 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?".
What is the difference, in terms of latency, between the following
signal chains in JACK?:
1) A/D -> A -> B -> A -> D/A
and
2) A/D -> A[B as plugin] -> -> D/A
and
3) A/D -> A -> B -> C -> D/A
Why is there additional latency added to client B in 1) but not 3),
especially in the case where C could be another instance of A?
And also, could the following section the JACK faq perhaps be altered
to provide some clarification here:
Doesn't use JACK add latency?
There is /NO/ extra latency caused by using JACK for audio input
and output. When we say none, we mean absolutely zero. The only
impact of using JACK is a slight increase in the amount of work
done by the CPU to process a given chunk of audio, which means
that in theory you could not get 100% of the processing power that
you might get it if your application(s) used ALSA or CoreAudio
directly. However, given that the difference is less than 1%, and
that your system will be unstable before you get close to 80% of
the theoretical processing power, the effect is completely
disregardable.
I understand that this explicitly says "using JACK for audio input and
output", but the question itself is a little broader than that. To me
it implies that the entire JACK graph adds no additional latency. If I
can be pointed to a clarified explanation of the matter I'd happily
provide some documentation if no one else has the time or inclination.
regards
michael
I also wonder why JACK's zero-copy implementation could cause issues for
audio apps. There was an issue for Qtractor, anyway, until today I
believed that there is no latency when using JACK in any way, excluded
connections regarding to the sound card.
I never noticed a latency, but maybe it's because I used this insert
connections for time related FX only, e.g. flanger and delay.
Interesting to read about latency I never was able to hear.
Ralf
11:20 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Hey guys!
I was the one who tested this for Mike. I used Qtractor and Rakarrack.
In Qtractor I had Audio track 1 and Audio track 2.
Signal from track 1 was routed into Rakarrack and then into track 2.
The latency is there and quite audible.
Louigi.
11:25 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Louigi Verona wrote:
Hey guys!
I was the one who tested this for Mike. I used Qtractor and Rakarrack.
In Qtractor I had Audio track 1 and Audio track 2.
Signal from track 1 was routed into Rakarrack and then into track 2.
The latency is there and quite audible.
Louigi.
Maybe it has nothing to do with this:
-------- Original Message --------
Subject: Re: [LAD] JACK Graph Internal Latency? (was Re: A small
article ...)
Date: Thu, 29 Apr 2010 11:17:31 +0200
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: michael noble <looplog(a)gmail.com>
CC: linux-audio-dev(a)lists.linuxaudio.org
References:
<s2q339c30111004281945ke03e953dp404e0b63e42b563d(a)mail.gmail.com>
<m2yeb4b5e1d1004282041j67fd5bcek60636d345c38ba0f(a)mail.gmail.com>
<l2y339c30111004282258rfd24b69bo3f86bbd54235ff12(a)mail.gmail.com>
<p2p339c30111004290202u6fec7788ka4b038632ac42c87(a)mail.gmail.com>
[snip]
I also wonder why JACK's zero-copy implementation could cause issues
for
audio apps. There was an issue for Qtractor, anyway, until today I
believed that there is no latency when using JACK in any way, excluded
connections regarding to the sound card.
I never noticed a latency, but maybe it's because I used this insert
connections for time related FX only, e.g. flanger and delay.
Interesting to read about latency I never was able to hear.
Ralf
But anyway, what version of Qtractor do you use? There was an issue
related to a supposed zero-copy implementation for outdated versions of
Qtractor, that a long time ago was fixed in SVN or even in the
previously used CVS.
Ralf
11:27 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
My version is 0.44, I think. pretty late one, I compiled ot from git in
February or January.
I can try another version or another app for that matter. But let Paul tell
us if it makes sense at all.
On Thu, Apr 29, 2010 at 1:25 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote:
Louigi Verona wrote:
Hey guys!
I was the one who tested this for Mike. I used Qtractor and Rakarrack.
In Qtractor I had Audio track 1 and Audio track 2.
Signal from track 1 was routed into Rakarrack and then into track 2.
The latency is there and quite audible.
Louigi.
Maybe it has nothing to do with this:
-------- Original Message --------
Subject: Re: [LAD] JACK Graph Internal Latency? (was Re: A small
article ...)
Date: Thu, 29 Apr 2010 11:17:31 +0200
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: michael noble <looplog(a)gmail.com>
CC: linux-audio-dev(a)lists.linuxaudio.org
References: <
s2q339c30111004281945ke03e953dp404e0b63e42b563d(a)mail.gmail.com>
<m2yeb4b5e1d1004282041j67fd5bcek60636d345c38ba0f(a)mail.gmail.com>
<l2y339c30111004282258rfd24b69bo3f86bbd54235ff12(a)mail.gmail.com>
<p2p339c30111004290202u6fec7788ka4b038632ac42c87(a)mail.gmail.com>
[snip]
I also wonder why JACK's zero-copy implementation could cause issues
for
audio apps. There was an issue for Qtractor, anyway, until today I
believed that there is no latency when using JACK in any way, excluded
connections regarding to the sound card.
I never noticed a latency, but maybe it's because I used this insert
connections for time related FX only, e.g. flanger and delay.
Interesting to read about latency I never was able to hear.
Ralf
But anyway, what version of Qtractor do you use? There was an issue related
to a supposed zero-copy implementation for outdated versions of Qtractor,
that a long time ago was fixed in SVN or even in the previously used CVS.
Ralf
11:32 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Louigi Verona wrote:
My version is 0.44, I think. pretty late one, I
compiled ot from git
in February or January.
I can try another version or another app for that matter. But let Paul
tell us if it makes sense at all.
I guess Rui programmed buggy for Qtractor, it wasn't a fault for JACK1
or JACK2. Perhaps 4.4.5+ is needed.
11:44 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Well, from what Paul said it appears it is not Qtractor, it is the same with
Ardour and basically just any loop connections setup.
Or am I getting it incorrectly? Let's wait for what Paul has to say %)
On Thu, Apr 29, 2010 at 1:32 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote:
Louigi Verona wrote:
My version is 0.44, I think. pretty late one, I
compiled ot from git in
February or January.
I can try another version or another app for that matter. But let Paul
tell us if it makes sense at all.
I guess Rui programmed buggy for Qtractor, it wasn't a fault for JACK1 or
JACK2. Perhaps 4.4.5+ is needed.
12:07 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
From my experience it's a question of client
design.
To loop a jack-client in a other jack-client there must be explicit
call's to the jack_buffer. Mean when I send out the data to the
jack_buffer, to a other client, I must make again a call (in the same
callback process) to the jack_buffer to recive the data.
port_1(get_buffer) -> outside_client -> port_2 (get_buffer)
Most jack applications be designed to receive the buffer for all ports
in one call.
for (int i = 0; i < 2; i++)
gInChannel[i] = (float
*)jack_port_get_buffer(input_ports[i], nframes);
process loop;
for (int i = 2; i < gNumInChans; i++)
gInChannel[i] = (float
*)jack_port_get_buffer(input_ports[i], nframes);
greats hermann
Am Donnerstag, den 29.04.2010, 13:44 +0400 schrieb Louigi Verona:
Well, from what Paul said it appears it is not
Qtractor, it is the
same with Ardour and basically just any loop connections setup.
Or am I getting it incorrectly? Let's wait for what Paul has to say %)
On Thu, Apr 29, 2010 at 1:32 PM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Louigi Verona wrote:
My version is 0.44, I think. pretty late one, I
compiled ot from git in February or January.
I can try another version or another app for that
matter. But let Paul tell us if it makes sense at all.
I guess Rui programmed buggy for Qtractor, it wasn't a fault
for JACK1 or JACK2. Perhaps 4.4.5+ is needed.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:41 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, 29 Apr 2010 13:44:02 +0400, Louigi Verona
<louigi.verona(a)gmail.com>
wrote:
Well, from what Paul said it appears it is not
Qtractor, it is the same
with
Ardour and basically just any loop connections setup.
Or am I getting it incorrectly? Let's wait for what Paul has to say %)
On Thu, Apr 29, 2010 at 1:32 PM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>wrote;wrote:
> Louigi Verona wrote:
>
>> My version is 0.44, I think. pretty late one, I compiled ot from git
in
>> February or January.
>> I can try another version or another app for that matter. But let Paul
>> tell us if it makes sense at all.
>>
>
> I guess Rui programmed buggy for Qtractor, it wasn't a fault for JACK1
or
> JACK2. Perhaps 4.4.5+ is needed.
>
the zero-copy issue was indeed a sloppy bug in older qtractor versions.
the issue at hand (OP) is that there bouncing, recording or feeding back
outputs to own inputs, which is quite equivalent to returns from sends on
inserts, adds at least one buffer or period cycle latency to the
bounced/return signal
bounce-recording:
qtractor-out -> rackarrak -> qtractor-in
as insert to track or bus:
qtractor-send -> rackarrak -> qtractor-return
you can swap qtractor for ardour, or anything else for that matter and the
latency will be exactly the same systematic. a client can only process the
results of its own outputs or sends in the _next_ process cycle.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
12:45 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
"you can swap qtractor for ardour, or anything else for that matter and the
latency will be exactly the same systematic. a client can only process the
results of its own outputs or sends in the _next_ process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the recording
took place.
Louigi.
3:13 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Louigi Verona wrote:
"you can swap qtractor for ardour, or anything
else for that matter
and the
latency will be exactly the same systematic. a client can only process the
results of its own outputs or sends in the _next_ process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the
recording took place.
Louigi.
Move the clip by drag'n'drop with the mouse, e.g. with the grid set to
Beat/96 a little bit to the left for the time line. Double-click on an
audio track to open the clip window, there you can edit the offset of
the clip, unfortunately negative values are impossible, at least for my
still outdated 0.4.5.1529, latest trunk is on 0.4.5.1557.
3:21 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, Apr 29, 2010 at 6:45 AM, Louigi Verona <louigi.verona(a)gmail.com>wrote;wrote:
"you can swap qtractor for ardour, or anything
else for that matter and the
latency will be exactly the same systematic. a client can only process the
results of its own outputs or sends in the _next_ process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the recording
took place.
Ardour specifically has a "nudge by period size" (since that is the offset
that results) for precisely this purpose.
--p
3:36 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, Apr 29, 2010 at 5:21 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Thu, Apr 29, 2010 at 6:45 AM, Louigi Verona <louigi.verona(a)gmail.com>wrote;wrote:
This is exactly how I thought it can be done! Great Paul, really nice job
you did!
I think Rui is planning to implement something of that sort as well.
"you can swap qtractor for ardour, or
anything else for that matter and
the
latency will be exactly the same systematic. a client can only process the
results of its own outputs or sends in the _next_ process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the
recording took place.
Ardour specifically has a "nudge by period size" (since that is the offset
that results) for precisely this purpose.
--p
3:49 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, 29 Apr 2010 17:36:43 +0400, Louigi Verona wrote:
This is exactly how I thought it can be done! Great Paul, really nice job
On Thu, Apr 29, 2010 at 5:21 PM, Paul Davis wrote:
> On Thu, Apr 29, 2010 at 6:45 AM, Louigi Verona wrote:
>
>> "you can swap qtractor for ardour, or anything else for that matter
and
>> the latency will be exactly the same
systematic. a client can only
process
the results of its own outputs or sends in the _next_
process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the
recording took place.
Ardour specifically has a "nudge by period size" (since that is the
offset that results) for precisely this purpose.
you did!
I think Rui is planning to implement something of that sort as well.
do i? :)
anyway, while on the clip properties dialog you can always alter the clip
start-time manually, in frames
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
4:32 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Rui Nuno Capela wrote:
On Thu, 29 Apr 2010 17:36:43 +0400, Louigi Verona
wrote:
This is exactly how I thought it can be done! Great Paul, really nice
job
As I've written before, unfortunately negative values aren't possible,
neither for the start-time nor for the offset-time.
OT: I guess today I'll upgrade Qtractor ;) and in coming days I should
go on testing, resp. using Qtractor, sorry for the rest ;D. For testing
purpose I'll switch to 64 Studio 3.3 alpha (Ubuntu Karmic), assumed that
I'm able to get ALSA seq repaired, it's written that it should be broken
... won't become too OT.
On Thu, Apr 29, 2010 at 5:21 PM, Paul Davis
wrote:
> On Thu, Apr 29, 2010 at 6:45 AM, Louigi Verona wrote:
>
>
>> "you can swap qtractor for ardour, or anything else for that matter
>>
and
>> the latency will be exactly the same
systematic. a client can only
>>
process
the results of its own outputs or sends in the _next_
process cycle."
Ha! Rui, that makes sense. Now I think I get it. Indeed.
I wonder if there is an easy way to compensate for this after the
recording took place.
Ardour specifically has a "nudge by period size" (since that is
the
offset that results) for precisely this purpose.
you did!
I think Rui is planning to implement something of that sort as well.
do i? :)
anyway, while on the clip properties dialog you can always alter the clip
start-time manually, in frames
cheers
11:28 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Ralf Mardorf wrote:
Louigi Verona wrote:
Do you know that you also could do real insert connections using Qtractor?
Hey guys!
I was the one who tested this for Mike. I used Qtractor and Rakarrack.
In Qtractor I had Audio track 1 and Audio track 2.
Signal from track 1 was routed into Rakarrack and then into track 2.
The latency is there and quite audible.
Louigi.
Maybe it has nothing to do with this:
-------- Original Message --------
Subject: Re: [LAD] JACK Graph Internal Latency? (was Re: A small
article ...)
Date: Thu, 29 Apr 2010 11:17:31 +0200
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: michael noble <looplog(a)gmail.com>
CC: linux-audio-dev(a)lists.linuxaudio.org
References:
<s2q339c30111004281945ke03e953dp404e0b63e42b563d(a)mail.gmail.com>
<m2yeb4b5e1d1004282041j67fd5bcek60636d345c38ba0f(a)mail.gmail.com>
<l2y339c30111004282258rfd24b69bo3f86bbd54235ff12(a)mail.gmail.com>
<p2p339c30111004290202u6fec7788ka4b038632ac42c87(a)mail.gmail.com>
[snip]
I also wonder why JACK's zero-copy implementation could cause issues
for
audio apps. There was an issue for Qtractor, anyway, until today I
believed that there is no latency when using JACK in any way, excluded
connections regarding to the sound card.
I never noticed a latency, but maybe it's because I used this insert
connections for time related FX only, e.g. flanger and delay.
Interesting to read about latency I never was able to hear.
Ralf
But anyway, what version of Qtractor do you use? There was an issue
related to a supposed zero-copy implementation for outdated versions
of Qtractor, that a long time ago was fixed in SVN or even in the
previously used CVS.
Ralf
3:12 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, Apr 29, 2010 at 5:02 AM, michael noble <looplog(a)gmail.com> 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
3:49 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Am Donnerstag, den 29.04.2010, 09:12 -0400 schrieb Paul Davis:
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.
That's make me wonder, because I'm doing exactly that.
I have a client, with two input ports, and two output ports. Now I
connect the first output with a external jack client, and feed the data
back to input port 2 of my client. I can mix the data now with the
(saved buffer) data from port 1 and send the mix to outputport 2.
All I need is a seperate process for etch port.
Here is the simplistic callback, I wonder why that consider to didn't
work ? Isn't it the same like connect any other client ?
Were is my error in understand jack ?
regards hermann
int gx_jack_process (jack_nframes_t nframes, void *arg)
{
gInChannel[1] = (float
*)jack_port_get_buffer(input_ports[1], nframes);
for (int i = 0; i < gNumOutChans; i++)
gOutChannel[i] = (float
*)jack_port_get_buffer(output_ports[i], nframes);
GxEngine::instance()->compute(nframes, gInChannel,
gOutChannel); // here we send data to a external client connected to
input 2
gInChannel[2] = (float
*)jack_port_get_buffer(input_ports[2], nframes);
GxEngine::instance()->compute2_output( gInChannel,
gOutChannel,nframes);
}
return 0;
}
4:02 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On Thu, Apr 29, 2010 at 9:49 AM, hermann <brummer-(a)web.de> wrote:
Am Donnerstag, den 29.04.2010, 09:12 -0400 schrieb
Paul Davis:
the data from the other JACK client isn't available just because you
delivered it to its input port. that other client has to actually run its
own process() callback. that doesn't happen while yours in running in. to
paraphrase your code:
int gx_jack_process (jack_nframes_t nframes, void *arg)
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.
That's make me wonder, because I'm doing exactly that.
I have a client, with two input ports, and two output ports. Now I
connect the first output with a external jack client, and feed the data
back to input port 2 of my client. I can mix the data now with the
(saved buffer) data from port 1 and send the mix to outputport 2.
All I need is a seperate process for etch port.
Here is the simplistic callback, I wonder why that consider to didn't
work ? Isn't it the same like connect any other client ?
Were is my error in understand jack ?
{
get_the_input1_buffer ();
get_the_output_buffers ();
compute_output_data (); // delivers to outputs
get_the_input2_buffer ();
}
the problem is that the contents of "input2" is just the same at any point
during this entire function because the other client has *not* executed its
process() callback.
what you are reading from input2 is what the other client executed *last*
time it executed its process callback().
4:35 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Am Donnerstag, den 29.04.2010, 10:02 -0400 schrieb Paul Davis:
the data from the other JACK client isn't
available just because you
delivered it to its input port. that other client has to actually run
its own process() callback. that doesn't happen while yours in running
in. to paraphrase your code:
int gx_jack_process (jack_nframes_t nframes, void *arg)
{
get_the_input1_buffer ();
get_the_output_buffers ();
compute_output_data (); // delivers to outputs
get_the_input2_buffer ();
}
the problem is that the contents of "input2" is just the same at any
point during this entire function because the other client has *not*
executed its process() callback.
what you are reading from input2 is what the other client executed
*last* time it executed its process callback().
So, the "next client" didn't start processing before my client have
completed the callback full (return), that's it ?
Okay, thanks for clarification
greats hermann
4:37 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
Thanks Paul and Rui for both of your explanations. This actually fills a
huge gap in my understanding of how the audio graph works, so much
appreciated for taking the time to answer.
-michael
3:10 p.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
2010/4/29 Paul Davis <paul(a)linuxaudiosystems.com>om>:
there have been some suggestions to allow/encourage
applications to have
multiple clients precisely to permit the A->B->A ("insert") processing
to
work with no extra latency.
This is very interesting, how would that be possible?
BR,
Stefano
6:44 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On April 28, 2010 10:45:28 pm you wrote:
hi all,
On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech(a)rogers.com> wrote:
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.
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
7:41 a.m.
New subject: JACK Graph Internal Latency? (was Re: A small article ...)
On April 29, 2010 12:39:30 am Tim E. Real wrote:
On April 28, 2010 10:45:28 pm you wrote:
Oops, yeah that
happens, but all within one process cycle.
Each plugin in the chain is run in succession on the data, right?
My mistake. Must be tired, the ol' brain wanders...
hi all,
On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech(a)rogers.com> wrote:
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.") 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
Tim.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5355
days inactive
5355
days old
linux-audio-dev@lists.linuxaudio.org
26 comments
8 participants
participants (8)
-
hermann -
Louigi Verona -
michael noble -
Paul Davis -
Ralf Mardorf -
Rui Nuno Capela -
Stefano D'Angelo -
Tim E. Real