[Jack-Devel] questions about latency ranges

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] questions about latency ranges

Markus Grabner-2
        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?
*) 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"?

        Thanks & kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Robin Gareus
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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Xavier Mendez
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:
https://github.com/jmendeth/jack-tools/tree/latency-tools

Xavi

El 15/11/17 a les 03:46, Robin Gareus ha escrit:

> 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Markus Grabner
In reply to this post by Robin Gareus
Am Mittwoch, 15. November 2017, 03:46:41 CET schrieb Robin Gareus:
> On 11/14/2017 11:50 PM, Markus Grabner wrote:
> > 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.
Ok, then it's an Ardour issue. There are actually several opportunities to
mess things up when reimplementing jack's latency propagation algorithm in a
client's latency callback. What do you think about making jack's original
algorithm available to the client such that a client's latency callback (e.g.,
for adding 100 frames of latency) could be something like

void latency_callback(jack_latency_callback_mode_t mode, void *arg)
{
        jack_latency_range_t range;
        jack_port_compute_latency_range(port, mode, &range);  // new
        range.min += 100;
        range.max += 100;
        jack_port_set_latency_range(port, mode, &range);
}

I guess this could be useful in many cases when a client needs its own latency
callback.

> I guess you use alsa_in or zita-aj2 for port "B", the latter tool has
> options to set additional systemic latencies.
Yes (as I stated before), and the systemic latencies are set to the values
reported by Jack_delay (http://kokkinizita.linuxaudio.org/linuxaudio).

> 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)
Interesting, I will at least have a look at this.

        Thanks & kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Markus Grabner
In reply to this post by Xavier Mendez
Am Mittwoch, 15. November 2017, 15:33:29 CET schrieb Xavier Mendez:
> (shameless self-citation) I made jack_lsync that does this, both
> jack_lset and jack_lsync can be found in:
> https://github.com/jmendeth/jack-tools/tree/latency-tools
Excellent, I was just starting to implement a similar tool myself, you saved
me a lot of work! Dropping in two instances of your client in the capture and
playback path precisely aligns the round-trip pulses in my Ardour test setup
(even in the pathological case that both signals are recorded into the same
track).

I vote for adding these tools to the Jack example clients. What do you think
about this?

BTW, one question regarding the "coefficient" parameter: I thought this should
always be "1" (align to maximum latency), but didn't notice any difference
when leaving its default value 0.5 (align to center), both variants gave
correct results. How does this coefficient affect the behaviour of your client?

        Thanks & kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Xavier Mendez
El 18/11/17 a les 00:50, Markus Grabner ha escrit:

> Am Mittwoch, 15. November 2017, 15:33:29 CET schrieb Xavier Mendez:
>> (shameless self-citation) I made jack_lsync that does this, both
>> jack_lset and jack_lsync can be found in:
>> https://github.com/jmendeth/jack-tools/tree/latency-tools
> Excellent, I was just starting to implement a similar tool myself, you saved
> me a lot of work! Dropping in two instances of your client in the capture and
> playback path precisely aligns the round-trip pulses in my Ardour test setup
> (even in the pathological case that both signals are recorded into the same
> track).
>
> I vote for adding these tools to the Jack example clients. What do you think
> about this?

It'd be nice if they also supported synchronizing MIDI ports, but that's
TODO for now. For the rest, IMO they're pretty much ready to go.

>
> BTW, one question regarding the "coefficient" parameter: I thought this should
> always be "1" (align to maximum latency), but didn't notice any difference
> when leaving its default value 0.5 (align to center), both variants gave
> correct results. How does this coefficient affect the behaviour of your client?

The coefficient has no effect when all ports' input latency has the same
minimum and maximum (i.e. one port [ 337 337 ] and the other [ 867 867
]). That's expected most of the time.

If one port had [ 523 1024 ] latency you'd probably be doing it wrong,
but jack_lsync still has to deal with it, and that's what the parameter
is for. If coefficient was 0, lsync would assume 523 latency when
calculating the delays to apply, if it's 1 it'll assume 1024, and if
it's the default it'll just take the mean of min & max, and assume 773.

So it's only there for those strange cases that should ideally never happen.

PS: If you want to use alsa_out or alsa_in, note this bug which may make
them report wrong playback/capture latencies in some cases
https://github.com/jackaudio/tools/pull/8

Xavi

>
> Thanks & kind regards,
> Markus
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: questions about latency ranges

Markus Grabner
Am Samstag, 18. November 2017, 21:55:14 CET schrieb Xavier Mendez:
> El 18/11/17 a les 00:50, Markus Grabner ha escrit:
> > I vote for adding these tools to the Jack example clients. What do you
> > think about this?
>
> It'd be nice if they also supported synchronizing MIDI ports, but that's
> TODO for now. For the rest, IMO they're pretty much ready to go.
I agree, MIDI would be nice to have, but the tools would be a useful addition
even without MIDI support. Any opinions of other Jack developers on this?

> > BTW, one question regarding the "coefficient" parameter: I thought this
> > should always be "1" (align to maximum latency), but didn't notice any
> > difference when leaving its default value 0.5 (align to center), both
> > variants gave correct results. How does this coefficient affect the
> > behaviour of your client?
> The coefficient has no effect when all ports' input latency has the same
> minimum and maximum (i.e. one port [ 337 337 ] and the other [ 867 867
> ]). That's expected most of the time.
>
> If one port had [ 523 1024 ] latency you'd probably be doing it wrong,
> but jack_lsync still has to deal with it, and that's what the parameter
> is for. If coefficient was 0, lsync would assume 523 latency when
> calculating the delays to apply, if it's 1 it'll assume 1024, and if
> it's the default it'll just take the mean of min & max, and assume 773.
>
> So it's only there for those strange cases that should ideally never happen.
Ok, a device not knowing exactly its own latency is indeed odd. Thanks for the
explanation!

> PS: If you want to use alsa_out or alsa_in, note this bug which may make
> them report wrong playback/capture latencies in some cases
> https://github.com/jackaudio/tools/pull/8
Thanks for the hint, but due to another self-citation :-) a while ago by Fons
Adriaensen, I ended up using Zita-ajbridge (http://kokkinizita.linuxaudio.org/
linuxaudio/zita-ajbridge-doc/quickguide.html), which works very well for me.

        Kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org