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