On 4/6/19 7:07 AM, Alexandre BIQUE wrote:
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.
That would be counter-productive. You statement is also not correct.
jack clients can correctly compensate for latency, and also do that in
situations when no audio hardware is involved.
The fact that not all jack clients do this is not reason to constrain
Then let the client query the audio interface latency
and job done.
Only MacOS/X offers an interface to query systemic latency from hardware
It will work well for clients that uses jack as an
If you don't need to do inter-application routing, I would highly
recommend against using JACK only to abstract a single audio interface.
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.
A user asking for ambiguous latency situations is not an design issue
with JACK. The 'range' was specifically added to account for this and
allow jack-clients to cope with it.