[Jack-Devel] I'm confused about latency

[Robin Gareus]

On 4/5/19 10:32 PM, Alexandre BIQUE wrote:
> On 4/5/19 6:15 PM, Robin Gareus wrote:
>> If you meant that App1 is latent, and App2's input-port is connected to
>> the sum of App1's output and the HW's capture port. Then the latency is
>> ambiguous (jack reports a range).
>>
>> If App1 doesn't introduce a latency. App2 will see a single value for
>> the capture-latency on its input port.
>>
>> jack does not include a "delay in the wire" to align paths. JACK is a
>> patchbay. It provides mechanism for efficient inter-application
>> connections, jackd itself does not enforce a policy on the user.
> 
> Yeah that's my issue, the latency problem can't be solved.

Why is this a problem? If you want to shoot yourself in the foot you can
do the exact same with an analog patchbay. Comb filter galore! :)

The jack UI front-end can try to educate a user why some routing
situations may not make sense. It may also suggest to the user to add a
no-op, delayline to compensate for the ambiguity  --  but JACK itself
doesn't care.

> Maybe jack would be clearer without the port's latency and a simple way
> to query the audio driver latency.

Why and how would that help?

Would you mind elaborating why you think that querying an application's
*port* capture and playback latencies is not the correct solution in an
anywhere to anywhere routing system?

In some cases there may not be any hardware involved at all, and in the
vast majority of cases port latencies are not ambiguous.


The case of a direct parallel bypass around a latent App1 like
  HW Input] -> [App1] -> [App2] -> [HW Output]
           `-----------^
is really a constructed situation. JACK is not a modular synth, but a
patchbay.

2c,
robin