4 May
2011
4 May
'11
3:38 p.m.
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