6 Apr
2019
6 Apr
'19
12:07 a.m.
On 4/6/19 1:13 AM, Robin Gareus wrote:
On 4/5/19 10:32 PM, Alexandre BIQUE wrote:
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
On 4/5/19 6:15 PM, Robin Gareus wrote:
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.
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. 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.