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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
