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