It's been interesting seeing all the results from
xruncounter. Good job tramp.
xruncounter produces two results : the DSP load at which the first Xrun happens, and how many circles or cycles it took to produce that DSP load. A well configured system doesn't produce Xruns until ~98% DSP load. The number of cycles it took to produce that DSP load tells us the power of the system, which tells us how many plugins and soft synths we can expect to run. The more cycles, the more plugins.
When interpreting results we can consider DSP load
and the number of cycles. We do want the DSP load where the first Xrun happens to be as high as possible; we also want the maximum number of cycles. Here's an example :
lilith wrote:This is how it looks for me... not that good :/
Code: Select all
first Xrun happen at DSP load 83.043152 circle 41055
I tried with the Debian stock kernel and it's slightly better (maybe the same within the reproducibility)
Code: Select all
first Xrun happen at DSP load 87.472519 circle 40284
I would think the second result is worse for two reasons. First the number of cycles is less, so that means less plugins. Secondly if the stock system got to ~100% DSP load it would do so in less cycles than the RT system. Less cycles means less plugins even if the configuration of the stock system is optimised. To put it another way, the stock system has a higher DSP load at a lower number of cycles. This shows that the stock kernel is worse for processing audio, specifically using JACK -- this is what we expect and fits with the received wisdom.
@windowsrefund -- If we take DSP load
and number of cycles into account, 3 periods isn't performing better.
windowsrefund wrote:With Jack Periods set to 2
Code: Select all
first Xrun happen at DSP load 81.481308 circle 41250
With Jack Periods set to 3
Code: Select all
first Xrun happen at DSP load 93.284630 circle 43342
With JACK periods set to 2, your system Xruns at 81% and 41250 cycles. So say you tweaked a few things and got to 93%, as you did with 3 periods, how many cycles would that be? It's 41250 * (93/81) = 47361, which is more than the 43342 you got with 3 periods. Although you got to a higher DSP load and did squeeze a bit more out the system the 3 period system is actually performing less well.
Adding another period introduces more latency. Going from 2 periods to 3 periods increases latency by 50%, which you've traded for a 5% (43342/41250) increase in performance. In my tests latency and cycles have a nearly straight line relationship. If I half the latency by halving the buffer size or doubling the sample rate, I get roughly half the number of cycles.
To attempt to clarify : Actual buffer size = (frames per period) * (periods).
'Frame' is a fancy word for 'sample' or 'group of samples' e.g. 2 samples in stereo. 'Frames per period' is what
xruncounter calls 'buffersize'. And 'periods' are 'periods'. I've heard that 3 periods is better for USB devices. You have an internal soundcard, so probably 2 is best. Cadence reports 'block latency' which is (frames per period/sample rate). Qjackctl reports (block latency*periods).
I think you could tweak your system to get better performance. The first thing I thought of was "do you have Nvidia proprietary drivers?".
To summarise : when using
xruncounter DSP load where the first Xrun occurs taken together with number of cycles tells us about the performance of a system.