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

Paul Davis paul at linuxaudiosystems.com
Thu Apr 29 14:02:06 UTC 2010

On Thu, Apr 29, 2010 at 9:49 AM, hermann <brummer- at web.de> wrote:

> 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 ?

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().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100429/f5408684/attachment.html>

More information about the Linux-audio-dev mailing list