7 Apr
2016
7 Apr
'16
1:57 a.m.
On 04/06/2016 11:27 PM, Fons Adriaensen wrote:
On Wed, Apr 06, 2016 at 12:26:32AM +0200, Alexandre
DENIS wrote:
How would that effectively differ from running at twice the buffersize?
That approach just moves the load to two CPU cores. If those two cores
can produce the result in a given time, a single core can do the same
with twice the buffersize. Identical total latency.
2c,
robin
I think it should be doable to write a simple
client that connects as
two unrelated clients to jack, and feeds its outputs with its inputs
with one period of delay. It will make jack2 run the client connected
to its inputs and to its outputs in parallel, since jackd doesn't see
it as a dependency; but the latency of one period is unavoidable, since
we cannot predict whether jackd will invoke first the callback for the
inputs or for the output (or maybe at the same time on different
cores).
The latency is indeed unavoidable, but not for the reason
you mention. The order of execution of the two parts of
the 'delay' client must not be random.
You need to ensure that the 'in' client runs after the 'out'
client. This can be done easily by having a dummy connection.
In other words, you'd have something like
X -> [ A <- B ] -> Y
Then in each cycle X and B can run immediately. B copies
the data input by A in the previous cycle to its outputs
(this can be very fast), then Y runs while X can still
be busy. When X terminates, A stores the data to be read
by B in the next cycle.
In case X terminates before B, A still has to wait for
B to terminate - this ensures that Y always has the
one cycle delayed output from X.