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
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:
Any informed input would be highly appreciated!
thx and best regards, Stefan
measured rtl twice as high as calculated one
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 2083
- Joined: Mon Sep 28, 2015 8:06 pm
- Location: Here, of course!
- Has thanked: 232 times
- Been thanked: 400 times
- Contact:
Re: measured rtl twice as high as calculated one
I think you'll find that jack reports the one-way latency, while reaper adds both in and out latencies.
The Yoshimi guy {apparently now an 'elderly'}
Re: measured rtl twice as high as calculated one
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
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
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: measured rtl twice as high as calculated one
This may explain it a bit:
viewtopic.php?p=82736#p82736
viewtopic.php?p=82736#p82736
On the road again.
Re: measured rtl twice as high as calculated one
thx tramp for the hint! Will look into it!
regards, Stefan
regards, Stefan
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: measured rtl twice as high as calculated one
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.
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
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
There's always something to learn!
Best regards stefan