I still don't understand what's happening on the OP example. If both A
and B are connected to C, you really should be getting capture latency
of [ 337 867 ] there.
I created a quick test setup:
$ jackd -d dummy -r 48000 -p 2048 -C 0 -P 1 &
$ jack_lset -n source1 --capture 337 &
$ jack_lset -n source2 --capture 867 &
$ jack_connect source2:output_1 system:playback_1
$ jack_connect source1:output_1 system:playback_1
$ jack_lsp -l
system:playback_1
port latency = 4096 frames
port playback latency = [ 4096 4096 ] frames
port capture latency = [ 337 867 ] frames
source1:output_1
port latency = 0 frames
port playback latency = [ 4096 4096 ] frames
port capture latency = [ 337 337 ] frames
source2:output_1
port latency = 0 frames
port playback latency = [ 4096 4096 ] frames
port capture latency = [ 867 867 ] frames
JACK should always set the minimum value of the pair to the minimum
among its connected ports, not set both values to the maximum. Am I
missing something here?
You could add a jack-client in-between that delays the
signal and sets
port-latencies to include the delay.
(shameless self-citation) I made jack_lsync that does this, both
jack_lset and jack_lsync can be found in:
On 11/14/2017 11:50 PM, Markus Grabner wrote:
Hi!
I have some questions about the minimum and maximum values of a port's latency
(i.e., its latency range). The documentation states the following:
"Both latencies might potentially have more than one value because there may
be multiple pathways to/from a given port and a terminal port."
Does this also apply to a setup with two output ports "A" and "B"
(representing two distinct physical devices) with different capture latency,
which are both connected to the same input port "C"?
Here are some details of an example setup (useful for demonstration purposes,
but probably not for doing any real recording work) as reported by jack_lsp:
"A" (Focusrite Saffire PRO 14 Firewire audio interface):
firewire_pcm:00130e0402403491_1394/Out:01 (Mic/Lin/Inst:01)_in
port latency = 337 frames
port playback latency = [ 0 1792 ] frames
port capture latency = [ 337 337 ] frames
properties: output,physical,terminal,
"B" (Line6 PODxt Live guitar effects processor synchronized by zita-ajbridge):
line6_in:capture_1
port latency = 867 frames
port playback latency = [ 1792 1792 ] frames
port capture latency = [ 867 867 ] frames
properties: output,physical,terminal,
"C" (Ardour track):
ardour:track 1/audio_in 1
port latency = 0 frames
port playback latency = [ 1792 1792 ] frames
port capture latency = [ 867 867 ] frames
properties: input,
Under the assumption that the physical inputs of "A" and "B"
represent the
same time scale, the correct answer for the port capture latency at port "C"
would be [ 337 867 ] and not [ 867 867 ].
So my questions are:
*) What is the rationale behind jack reporting the larger of the two latencies
of "A" and "B" both as the minimum and maximum latency of
"C", and ignoring
the smaller one?
In this case it's Ardour (not JACK) that sets the port latencies. I
guess you use Ardour5 which [wrongly] always reports the worst-case latency.
*) Is it possible to provide additional
information to jack to state that the
signals at "A" and "B" originate from the same physical source (or
from
different physical sources sharing the same time scale), such that both
latencies of "A" and "B" are taken into account for the latency range
of "C"?
I guess you use alsa_in or zita-aj2 for port "B", the latter tool has
options to set additional systemic latencies.
Just forcing the values to some different number won't help you.
You could add a jack-client in-between that delays the signal and sets
port-latencies to include the delay.
Or wait for Ardour6 which already does this, but but at this point in
time is still far from a release, and the session format is not stable)
ciao,
robin
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org