Re: [LAU] multiJACK patch management: the first glimmerings of success

On 04/06/2016 11:27 PM, Fons Adriaensen wrote:
> On Wed, Apr 06, 2016 at 12:26:32AM +0200, Alexandre DENIS wrote:
>
>> 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.
>

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Apr 7 04:15:02 2016