thetotalchaos wrote: ↑Fri Mar 20, 2020 9:58 pm
Logically it should measure on its own. Otherwise its just a xrun display.
Nope. xruncounter is a stress test. It will force a xrun anyway by increasing the dsp load on any callback since xruns appears. It messure the CPU load and the dsp load to give you a hint if your system is setup well for pro audio usage. Regardless if you use a other jack aware application at the same time or not.
As pointed out already, when the results been worse with Renoise for example, running aside, it's a clear hint that Renoise (or one of the plugins it use) produce spikes in the dsp load. As the dsp load is a average value you couldn't see the spices in the dsp load values, but you should properly see them in the CPU load values.
So, when all cores goes to 100% it's likely that you produce a xrun, regardless what the dsp load value shows.
It's even possible when just one core reach 100% and do a context switch.
That's why I pointed out earlier that in my experiences it is much more important to have the best matching boot parameters for your board/cpu combo, then any priority switching you could do.
You all may have noticed the effect of the CPU governor settings, were without setting it to performance you can't reach a good stable audio system. There a a couple of more switches for the cpu's which have by far more influence on the performance of your system, then anything you could do with the priority settings.
On the road again.