[Jack-Devel] I'm confused about latency

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

[Jack-Devel] I'm confused about latency

Alexandre Bique
Hi,

I've been reading the code of Ableon's LinkHut's jack backend.

https://github.com/Ableton/link/blob/master/examples/linkaudio/AudioPlatform_Jack.hpp
https://github.com/Ableton/link/blob/master/examples/linkaudio/AudioPlatform_Jack.cpp

And I was quite surprised because I did not find any latency compensation there.
So for real-time beat time synchronization this is quite important right?
BTW, if any jack expert finds the time and motivation to fix the jack
back-end of Link's example that would be awesome and a great example.

Then I've read the documentation:

http://jackaudio.org/api/group__LatencyFunctions.html

And I am totally confused.

Why a latency range? What is the use case for it?

How is the application supposed to work with multiple inputs and
outputs having each a different latency range?

What's the point of a latency range? If you're concerned about the
shortest path and the longest path, why wouldn't you be concerned
about any path in between?

How to know at which time on a given a clock (CLOCK_REALTIME or
CLOCK_MONOTONIC) a sample in the current process block will be played
on the sound card's output?

I've tried with qjackctl to set the periods/buffer to 12 with 2048
samples per buffer at 44100 Hz which is about half a second of
latency. Do you manage to get the correct latency reported with those
settings? See https://imgur.com/w45wsp8

Jack allows feedback routing, how do you deal with latency with such a graph?

I've been testing with Jack 1.9.12-8 on Archlinux and QJackCtl 0.5.6-1

Many thanks for your answer and your time,
Alexandre Bique
_______________________________________________
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: I'm confused about latency

Ralf Mardorf
On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote:
> I've tried with qjackctl to set the periods/buffer to 12 with 2048
> samples per buffer at 44100 Hz which is about half a second of
> latency. Do you manage to get the correct latency reported with those
> settings? See https://imgur.com/w45wsp8

Hi,

what's wrong with QjackCtl's calculation?

For the calculation I found a page that seemingly contains a typo.

"(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" -
https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface

It should read "s" not "ms".

(2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms

Regards,
Ralf


_______________________________________________
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: I'm confused about latency

Alexandre Bique
On 4/4/19 6:51 PM, Ralf Mardorf wrote:

> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote:
>> I've tried with qjackctl to set the periods/buffer to 12 with 2048
>> samples per buffer at 44100 Hz which is about half a second of
>> latency. Do you manage to get the correct latency reported with those
>> settings? See https://imgur.com/w45wsp8
>
> Hi,
>
> what's wrong with QjackCtl's calculation?
>
> For the calculation I found a page that seemingly contains a typo.
>
> "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" -
> https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface
>
> It should read "s" not "ms".
>
> (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms

The calculation seems fine to me, but do you get the same latency
reported by jack to the clients? This is the issue.

Alex.
_______________________________________________
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: I'm confused about latency

Thomas Brand
On Thu, April 4, 2019 20:23, Alexandre BIQUE wrote:

> On 4/4/19 6:51 PM, Ralf Mardorf wrote:
>
>> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote:
>>
>>> I've tried with qjackctl to set the periods/buffer to 12 with 2048
>>> samples per buffer at 44100 Hz which is about half a second of latency.
>>> Do you manage to get the correct latency reported with those
>>> settings? See https://imgur.com/w45wsp8
>>
>> Hi,
>>
>>
>> what's wrong with QjackCtl's calculation?
>>
>> For the calculation I found a page that seemingly contains a typo.
>>
>>
>> "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" -
>> https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_idea
>> l_for_usb_interface
>>
>> It should read "s" not "ms".
>>
>>
>> (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms
>>
>
> The calculation seems fine to me, but do you get the same latency
> reported by jack to the clients? This is the issue.
>

I just tried with the same setting to start jackd, and it only works for
n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller
periods 4 than 5 for capture"). However changing n is reflected on ports:
jack_lsp -l -L

system:capture_1
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 2048 frames
...
system:playback_1
        port playback latency = [ 4096 4096 ] frames
        port capture latency = [ 0 0 ] frames
        total latency = 4096 frames
..

I think latency in a graph is confusing per se. The points you made for
"shortest path" etc. make sense to me. I'm not sure if the semantics of
latency for ports and latency ranges are well enough documented. It can
get very complicated considering a graph with many ports each of which can
have another latency and a mixture of different latencies depending on
routing etc. I want to say you're not the only one confused here.

On the search of example clients or clients that make use of the latency
features inside jack, I didn't find anything quickly. I speculate that
this API isn't used much and could probably be a candidate to remove. It's
not unlike the session API that's sitting there but isn't used (much).

Did I understand your use case correctly: you want to be able to tell
(from a client's perspective) how long it will take from *now* (this
cycle) until the start of the buffer is played out (eg. the first sample
of buffer hits the DAC) ~ ??

Greetings
Thomas



_______________________________________________
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: I'm confused about latency

Alexandre Bique
On 4/4/19 8:41 PM, Thomas Brand wrote:

> On Thu, April 4, 2019 20:23, Alexandre BIQUE wrote:
>> On 4/4/19 6:51 PM, Ralf Mardorf wrote:
>>
>>> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote:
>>>
>>>> I've tried with qjackctl to set the periods/buffer to 12 with 2048
>>>> samples per buffer at 44100 Hz which is about half a second of latency.
>>>> Do you manage to get the correct latency reported with those
>>>> settings? See https://imgur.com/w45wsp8
>>>
>>> Hi,
>>>
>>>
>>> what's wrong with QjackCtl's calculation?
>>>
>>> For the calculation I found a page that seemingly contains a typo.
>>>
>>>
>>> "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" -
>>> https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_idea
>>> l_for_usb_interface
>>>
>>> It should read "s" not "ms".
>>>
>>>
>>> (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms
>>>
>>
>> The calculation seems fine to me, but do you get the same latency
>> reported by jack to the clients? This is the issue.
>>
>
> I just tried with the same setting to start jackd, and it only works for
> n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller
> periods 4 than 5 for capture"). However changing n is reflected on ports:
> jack_lsp -l -L
>
> system:capture_1
> port playback latency = [ 0 0 ] frames
> port capture latency = [ 2048 2048 ] frames
> total latency = 2048 frames
> ...
> system:playback_1
> port playback latency = [ 4096 4096 ] frames
> port capture latency = [ 0 0 ] frames
> total latency = 4096 frames
> ..

Here it works so this is the output:

jack_lsp -l -L
system:capture_1
        port latency = 2048 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 2048 frames
system:capture_2
        port latency = 2048 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 2048 frames
system:playback_1
        port latency = 24576 frames
        port playback latency = [ 24576 24576 ] frames
        port capture latency = [ 0 0 ] frames
        total latency = 24576 frames
system:monitor_1
        port latency = 0 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 0 frames
system:playback_2
        port latency = 24576 frames
        port playback latency = [ 24576 24576 ] frames
        port capture latency = [ 0 0 ] frames
        total latency = 24576 frames
system:monitor_2
        port latency = 0 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 0 frames
PulseAudio JACK Sink:front-left
        port latency = 0 frames
        port playback latency = [ 24576 24576 ] frames
        port capture latency = [ 0 0 ] frames
        total latency = 24576 frames
PulseAudio JACK Sink:front-right
        port latency = 0 frames
        port playback latency = [ 24576 24576 ] frames
        port capture latency = [ 0 0 ] frames
        total latency = 24576 frames
PulseAudio JACK Source:front-left
        port latency = 0 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 2048 frames
PulseAudio JACK Source:front-right
        port latency = 0 frames
        port playback latency = [ 0 0 ] frames
        port capture latency = [ 2048 2048 ] frames
        total latency = 2048 frames


> I think latency in a graph is confusing per se. The points you made for
> "shortest path" etc. make sense to me. I'm not sure if the semantics of
> latency for ports and latency ranges are well enough documented. It can
> get very complicated considering a graph with many ports each of which can
> have another latency and a mixture of different latencies depending on
> routing etc. I want to say you're not the only one confused here.
>
> On the search of example clients or clients that make use of the latency
> features inside jack, I didn't find anything quickly. I speculate that
> this API isn't used much and could probably be a candidate to remove. It's
> not unlike the session API that's sitting there but isn't used (much).
>
> Did I understand your use case correctly: you want to be able to tell
> (from a client's perspective) how long it will take from *now* (this
> cycle) until the start of the buffer is played out (eg. the first sample
> of buffer hits the DAC) ~ ??

Yes, and in my case I would be directly connected to the system playback
and I would have a latency of 24576 frames which seems correct.

But this value does not seem to include the hardware latency itself
right? I believe that there is a few micro seconds of hardware latency
that can be reported by the driver somehow? I think ASIOGetLatencies
does that right?

Thank you for your answer.

Regards,
Alexandre
_______________________________________________
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: I'm confused about latency

Alexandre Bique
In reply to this post by Thomas Brand
On 4/4/19 8:41 PM, Thomas Brand wrote:
> Did I understand your use case correctly: you want to be able to tell
> (from a client's perspective) how long it will take from *now* (this
> cycle) until the start of the buffer is played out (eg. the first sample
> of buffer hits the DAC) ~ ??

Yes, something equivalent to snd_pcm_htimestamp().
_______________________________________________
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: I'm confused about latency

Thomas Brand
On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote:

> On 4/4/19 8:41 PM, Thomas Brand wrote:
>
>> Did I understand your use case correctly: you want to be able to tell
>> (from a client's perspective) how long it will take from *now* (this
>> cycle) until the start of the buffer is played out (eg. the first sample
>>  of buffer hits the DAC) ~ ??
>
> Yes, something equivalent to snd_pcm_htimestamp().
>
>
This page has a nice diagram:
http://manual.ardour.org/synchronization/latency-and-latency-compensation/
I don't know how accurate the delay from data leaving jack until it is
heard at the analog output can be known. It's around 2.5 ms. But is it the
same for every ALSA device and driver? jack_iodelay can measure round-trip
latency and you could adjust your system based on jack_iodely output.

Greetings
Thomas


_______________________________________________
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: I'm confused about latency

Alexandre Bique
On 4/5/19 2:56 AM, Thomas Brand wrote:

> On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote:
>> On 4/4/19 8:41 PM, Thomas Brand wrote:
>>
>>> Did I understand your use case correctly: you want to be able to tell
>>> (from a client's perspective) how long it will take from *now* (this
>>> cycle) until the start of the buffer is played out (eg. the first sample
>>>  of buffer hits the DAC) ~ ??
>>
>> Yes, something equivalent to snd_pcm_htimestamp().
>>
>>
> This page has a nice diagram:
> http://manual.ardour.org/synchronization/latency-and-latency-compensation/
> I don't know how accurate the delay from data leaving jack until it is
> heard at the analog output can be known. It's around 2.5 ms. But is it the
> same for every ALSA device and driver? jack_iodelay can measure round-trip
> latency and you could adjust your system based on jack_iodely output.

2.5 ms is quite a lot, and should be somehow reported by device API
(ALSA, ASIO, CoreAudio, ...):
 - the driver should have a rough idea of how much hardware latency is
introduced by the audio interface
 - the OS should have a rough idea of how much scheduling/internals
latency is introduced

Even if those values are not correct if they can reduce the "error" it
is worth it right?

I'm skeptical that people want to put a feedback cable into their audio
interface and measure exactly how much latency is introduced, and then
configure their tools with some mystic latency compensation. I really
think that if we can get some values from the OS which minimize the
error that would be better.

Cheers,
Alexandre
_______________________________________________
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: I'm confused about latency

Alexandre Bique
In reply to this post by Thomas Brand
On 4/4/19 8:41 PM, Thomas Brand wrote:

> I just tried with the same setting to start jackd, and it only works for
> n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller
> periods 4 than 5 for capture"). However changing n is reflected on ports:
> jack_lsp -l -L
>
> system:capture_1
> port playback latency = [ 0 0 ] frames
> port capture latency = [ 2048 2048 ] frames
> total latency = 2048 frames
> ...
> system:playback_1
> port playback latency = [ 4096 4096 ] frames
> port capture latency = [ 0 0 ] frames
> total latency = 4096 frames
> ..
>
> I think latency in a graph is confusing per se. The points you made for
> "shortest path" etc. make sense to me. I'm not sure if the semantics of
> latency for ports and latency ranges are well enough documented. It can
> get very complicated considering a graph with many ports each of which can
> have another latency and a mixture of different latencies depending on
> routing etc. I want to say you're not the only one confused here.
>
> On the search of example clients or clients that make use of the latency
> features inside jack, I didn't find anything quickly. I speculate that
> this API isn't used much and could probably be a candidate to remove. It's
> not unlike the session API that's sitting there but isn't used (much).
>
> Did I understand your use case correctly: you want to be able to tell
> (from a client's perspective) how long it will take from *now* (this
> cycle) until the start of the buffer is played out (eg. the first sample
> of buffer hits the DAC) ~ ??

To get back to the port's latency configuration here a simple case:

[HW Input] -> [App] -> [HW Output]

Should the App set its input and output port latency to 0?

Or should the App set its port latency as follow:
 app.in.latency = hw_in.out.latency;
 app.out.latency = app.in.latency + app.internal_latency;

Or something else?

And internally the application would use the hw input latency and hw
output latency.

Is that all correct? Are my questions clear?

Thank you very much!

Alex.
_______________________________________________
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: I'm confused about latency

Ralf Mardorf
In reply to this post by Alexandre Bique
On Fri, 5 Apr 2019 10:36:02 +0200, Alexandre BIQUE wrote:
>2.5 ms is quite a lot

A lot of people don't care about it. A digital guitar stomp box might
allready add additional 5 ms and people often don't notice it.

>I'm skeptical that people want to put a feedback cable into their audio
>interface and measure exactly how much latency is introduced, and then
>configure their tools with some mystic latency compensation. I really
>think that if we can get some values from the OS which minimize the
>error that would be better.

On Linux Ardour suggests to measure the round trip latency and on
iOS Auria Pro suggests to do a measurement, too. The gearslutz.com
forums discussed this and recommend to measure if "you really need to
have sample accurate timing". It's not unusual to connect a cable and
to push a button and perhaps to manually add a value to a dialog, if
it shouldn't be automated. How should the additional device's latency
be reported for e.g. an ADAT device connected to the audio interface,
even if all other latency would be reported?
_______________________________________________
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: I'm confused about latency

Alexandre Bique
On 4/5/19 11:48 AM, Ralf Mardorf wrote:
> On Fri, 5 Apr 2019 10:36:02 +0200, Alexandre BIQUE wrote:
>> 2.5 ms is quite a lot
>
> A lot of people don't care about it. A digital guitar stomp box might
> allready add additional 5 ms and people often don't notice it.

The use case are Ableton link and midi clock, of course it won't be
perfect but any best effort we can do to make it more accurate is welcomed.

>> I'm skeptical that people want to put a feedback cable into their audio
>> interface and measure exactly how much latency is introduced, and then
>> configure their tools with some mystic latency compensation. I really
>> think that if we can get some values from the OS which minimize the
>> error that would be better.
>
> On Linux Ardour suggests to measure the round trip latency and on
> iOS Auria Pro suggests to do a measurement, too. The gearslutz.com
> forums discussed this and recommend to measure if "you really need to
> have sample accurate timing". It's not unusual to connect a cable and
> to push a button and perhaps to manually add a value to a dialog, if
> it shouldn't be automated. How should the additional device's latency
> be reported for e.g. an ADAT device connected to the audio interface,
> even if all other latency would be reported?

Yes I also think that if one can achieve this in a user friendly way it
can be interesting.

Thank you,
Alex.
_______________________________________________
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: I'm confused about latency

Robin Gareus
In reply to this post by Alexandre Bique
On 4/5/19 11:27 AM, Alexandre BIQUE wrote:

> To get back to the port's latency configuration here a simple case:
>
> [HW Input] -> [App] -> [HW Output]
>
> Should the App set its input and output port latency to 0?

No, it should propagate latencies. But in this simple case it's not
relevant at all.

A better example is

  [HW Input] -> [App1] -> [App2] -> [HW Output]

Each App is interested in two things:

 - how long has it been since the data read from a port arrived at the
edge of the graph (capture, from hw-input)
 - how long will it be until the data written to a given port will
arrive at the edge of the graph (playback, to hw-output)


App1 should read the HW input *capture*-latency from its input port, add
its own latency and inform App2 about the sum by setting the capture
latency of App1's output port.

Likewise, App2 should add its latency to the *playback* latency of its
output port and forward that to App1 by setting the playback latency of
App2's input port.

Please see
http://jackaudio.org/api/group__LatencyFunctions.html#ga7a8f181fcec32945db7b8e06ee1ca94b
That outlines above algorithm


One example use-case is Overdubs: e.g. App1 plays back, App2 adds some
latent effect (e.g. a Limiter). A musician listens to HW output, sings
along into the HW-input and App1 records it. The recording should be in
sync with the playack.

> And internally the application would use the hw input latency and hw
> output latency.

Yes, the port latencies, which may or may not be related to hardware.

-=-

As for absolute alignment, that's jack-transport or jack-time, which
provides a clock based on the soundcard's oscillator. -- unrelated to
the operating-system's time.

http://jackaudio.org/api/group__TimeFunctions.html

Hope that helps,
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: I'm confused about latency

Alexandre Bique
On 4/5/19 1:13 PM, Robin Gareus wrote:
> As for absolute alignment, that's jack-transport or jack-time, which
> provides a clock based on the soundcard's oscillator. -- unrelated to
> the operating-system's time.

Which API is jack using to access the soundcard's clock?

Thank your for your answer, yes that helps.

Alex.
_______________________________________________
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: I'm confused about latency

Alexandre Bique
In reply to this post by Robin Gareus
On 4/5/19 1:13 PM, Robin Gareus wrote:
> A better example is
>
>   [HW Input] -> [App1] -> [App2] -> [HW Output]

What about this one:

[HW Input] -> [App1] -> [App2] -> [HW Output]
           `-----------^

How is App2 supposed to work out its input latency?
_______________________________________________
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: I'm confused about latency

Robin Gareus
On 4/5/19 2:35 PM, Alexandre BIQUE wrote:

> On 4/5/19 1:13 PM, Robin Gareus wrote:
>> A better example is
>>
>>   [HW Input] -> [App1] -> [App2] -> [HW Output]
>
> What about this one:
>
> [HW Input] -> [App1] -> [App2] -> [HW Output]
>            `-----------^
>
> How is App2 supposed to work out its input latency?
>

It just looks up the value(s) from its input port(s):
 jack_port_get_latency_range(port, JackCaptureLatency, &latency_range);


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.

Cheers!
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: I'm confused about latency

Alexandre Bique
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.

Maybe jack would be clearer without the port's latency and a simple way
to query the audio driver latency.

Thanks,
Alex
_______________________________________________
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: I'm confused about latency

Robin Gareus
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.

2c,
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: I'm confused about latency

Alexandre Bique
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
_______________________________________________
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: I'm confused about latency

Fons Adriaensen-3
In reply to this post by Robin Gareus
On Sat, Apr 06, 2019 at 01:13:58AM +0200, Robin Gareus wrote:
 
> 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.

It's not really that far-fetched. I have this sort of situations all
the time.

Assuming the two inputs to App2 are mixed on a single Jack port, that
port will show different values for min and max latency.

Now is this a problem ? That depends on the actual use case. In many
cases it doesn't.

To the OP:

*If* the different latencies matter, there are two solutions.

1. Insert a delay in the HW -> App2 connection.
2. Use separate inputs on App2, each will report its
   latency and App2 can compensate for the difference.

Note that 2. would be entirely automatic if App2 is designed
to do this. That is why Jack's latency reporting works the
way it does.

--
FA

   








_______________________________________________
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: I'm confused about latency

Robin Gareus
In reply to this post by Alexandre Bique
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
others.

> Then let the client query the audio interface latency and job done.

Only MacOS/X offers an interface to query systemic latency from hardware
interfaces.

> It will work well for clients that uses jack as an audio interface:

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.

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