[Jack-Devel] I'm confused about latency

Alexandre BIQUE bique.alexandre at gmail.com
Sat Apr 6 07:07:35 CEST 2019


On 4/6/19 1:13 AM, Robin Gareus wrote:
> 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.
You explained it well, jack is a patch bay and does not intent to solve
the latency compensation, it is not its purpose right? jack allows
situations where the latency compensation can't be solved, and it will
sum different inputs with different latencies, so you can't do anything
about it as a client.

That being said I'm not complaining about jack working that way. It is a
patch bay and it is fine.

I'm complaining about port's having latency, which would let anyone
reading the API think that they should and could implement latency
compensation, while in the end I can't see a way to implement it as a
jack client. So a jack client can't make the promise to the user that it
will compensate the latency.

Which led me to the conclusion "less is more": strip down the latency
from the ports, make it clear that you can't write a jack client which
does correct latency compensation. Then let the client query the audio
interface latency and job done. It is simple to understand and easy to
implement as a client. It will work well for clients that uses jack as
an audio interface: HW In -> App -> HW Out.

To sum up in one sentence, in my opinion it is better to not have
latency compensation than having it working half of the time.

Regards,
Alexandre



More information about the Jackaudio mailing list