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