Page 1 of 1
measured rtl twice as high as calculated one
Posted: Sun Mar 22, 2020 12:09 pm
by sas300
Hi guys!
I am testing switching to linux as native reaper builds came available some time ago.
My current set up for testing is:
* elitebook haswell i7 with ubuntu studio with basic set up following
* babyface pro in class complient mode
* reaper
Question: i measured rtl with jack_iodelay and lsp latency plugin and get figures twice as high as the reported ones in reaper or jack. Why?
SR: 44.1
Buffer: 64 samples
Periods: 3
- Screenshot_2020-03-22_12-49-11.png (246.63 KiB) Viewed 1098 times
I can also hear/feel them when playing live guitar through this setup (that tends to work well/playable with win10 until ms releases some "upgrades", of course
I suspect a problem/misconfig with alsa here, as the problem remains with an alsa only setup as well, although the rtl is slightly better here:
- alsa_config.png (149.05 KiB) Viewed 1098 times
Any informed input would be highly appreciated!
thx and best regards, Stefan
Re: measured rtl twice as high as calculated one
Posted: Mon Mar 23, 2020 4:51 pm
by folderol
I think you'll find that jack reports the one-way latency, while reaper adds both in and out latencies.
Re: measured rtl twice as high as calculated one
Posted: Mon Mar 23, 2020 5:58 pm
by sas300
Hi, THX. But it seems to be the other way when you have a look at the screenshots, Reaper tells in and out latency (as does the jack frontend) but the RTL measurement with jackio_delay shows extra latency.
For the time being I just like to understand why, AD/DA conversion will add some extra samples, that I know but not that much..
Thx stefan
Re: measured rtl twice as high as calculated one
Posted: Tue Mar 24, 2020 8:45 am
by tramp
Re: measured rtl twice as high as calculated one
Posted: Tue Mar 24, 2020 6:52 pm
by sas300
thx tramp for the hint! Will look into it!
regards, Stefan
Re: measured rtl twice as high as calculated one
Posted: Thu Mar 26, 2020 12:13 pm
by merlyn
If we consider the case with JACK first : Reaper and QjackCtl agree on the latency -- it's ~4.3ms.
This is calculated from ((number of periods) * (samples per period)) / sample rate. In this case :
(3 * 64) / 44100 = 4.35 ms
jack_iodelay reports that the actual, measured round trip latency is ~12.4 ms. Some of the latency is coming from the hardware. According to
jack_iodelay 292 samples worth of latency comes from the hardware. 292 samples at 44.1 kHz is ~6.62 ms. So there's still ~1.42 ms of latency unaccounted for.
This is because QjackCtl and Reaper don't include JACK's input buffer in the calculation. So the formula for nominal round trip latency is :
((1 + number of periods) * (samples per period)) / sample rate. Plugging in the numbers :
(4 * 64) / 44100 = 5.8 ms
To make things easier we can forget the sample rate and use samples.
jack_iodelay reports a round trip latency of 548.596 samples. We've got 256 samples from JACK buffers and 292 samples from the hardware making a total of 548 samples. The fractional part of a sample is the latency introduced by the A/D and D/A convertors.
So far, so academic.
What you want is to get your latency down. The first thing you can try is to use two periods instead of three. The second thing is to try a sample rate of 48 kHz. 292 samples is a lot of hardware latency and it's possible this is coming from re-sampling.
Re: measured rtl twice as high as calculated one
Posted: Thu Mar 26, 2020 3:57 pm
by tramp
Next time I'll have a look at the screeny before I post.
That said,
@merlyn commes with the better explain!
Re: measured rtl twice as high as calculated one
Posted: Thu Mar 26, 2020 7:18 pm
by sas300
THX @merlyn and @tramp for the useful hints and humble explanation! Will test your suggestion to try different sample rates!
There's always something to learn!
Best regards stefan