sample rate: 48000
frames/period: 128
periods/buffer: 2
In the buttom right hand corner Qjackctl shows latency to be: 5.33 msec
set up qjackctl on my laptop with the same settings: also showed 5.33 msec
booted the system with realtime kernel and also showed 5.33 msec
so i’m guessing this is just the estimated latency of these numbers i inputted into qjackctl: sample/frames/period.
the ACTUAL latency has to be actually tested? and this latency number shown by qjackctl is basically pretty arbitrary then? what do you guys use to actually test the real latency?
Haven’t done any real testing of the actual latency, but I have been happy with what I have now on my rme. If you want to test the actual, physical latency you probably need to patch the physical output to the pohysical input on your soundcard, send out a click from a DAW and record it back in again. Comparing the waveforms of the out- and in signal on the timeline should give you an idea of the latency. Maybe there is a clever way to do this in sc, but I am not aware of one…
I have found that 5.33 msec latency is too low for my system. I was getting a lot of xruns when I had it that low. I shoot for 11 or 16 (10.6 is my current). I can’t tell the difference and my sound isn’t choppy any more.
Another point, something that I stumbled on, is this package: pulseaudio-module-jack
This was the missing piece that fixed most of the issues I was having with jack. I am running Ubuntu 18.04. This package makes jack and pulse play nicely, don’t know what it is doing exactly. I don’t know your distribution, but it’s probably available in your package repos.
Lastly, make sure when tweaking your jack settings that those settings are actually being used by the sc server by reading the server boot output. I had some issues tweaking settings in qjackctl, where the settings were not being saved out and the server was booting with old settings. It’s an issue that others have noticed. I think I eventually just rebooted my system and the settings took.