[Jack-Devel] 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