[LAD] Looping audio to oneself via Jack

Stéphane Letz letz at grame.fr
Wed May 4 13:38:56 UTC 2011

>> I can't tell you about jack API stuff that might be relevant but I can
>> tell you that it usually works, there's nothing in jack that forbids it.
>> There's one thing though you should be aware of: the output will reach
>> the input one processing cycle after the output was produced, hence it
>> will be delayed. This is simply a consequence of how jack works.
> This may be a long standing bug that has been reported before.
> The jack authors seem to see it as a 'feature'.
> The summing of signals connected to an input port is done when
> that port's owner calls jack_port_get_buffer(). There is an
> optimisation: when there is only one output connected, you
> just get a copy of its buffer pointer, the sample data is not
> copied to separate input buffer.
> Now if (1) you make a loopback AND (2) your app clears its
> output buffers at the start of the cycle AND (3) it does
> this before calling jack_port_get_buffer() on its inputs,
> then the looped back output will appear to be empty. 
> A workaround would be to ensure condition (3) is not true,
> i.e. call jack_port_get_buffer() on inputs before clearing
> your ouputs.
> But even that won't work if there is just one output connected
> to the loopback input: the optimisation means its data is not
> copied and you will see an empy buffer anyway.
> IMHO Jack should make a copy of an output buffer if it is
> looped back even if that would otherwise not be necessary.
> Not doing this violates assumptions that are (IMHO) very
> legitimately made by all authors: either that
> (1, strong form) input buffers do not change during a
> process callback, or
> (2, weaker form) they do not change after the call to
> jack_port_get_buffer().
> Ciao,
> -- 
> FA

The issue has (hopefully) been fixed in jack2 since a while, Fons have you ever tested?



More information about the Linux-audio-dev mailing list