LinuxMusicians

Posted: **Fri Mar 20, 2020 9:58 pm**

lilith wrote: ↑Fri Mar 20, 2020 9:15 pm As far as I understand it slowly increases the DSP load and detects at which DSP load the first xruns appears. In addition it also shows the number of cycles. If your system is well configured you should reach 95% or more. What I don't understand is if a DAW that runs with higher priority in the background affects the outcome of xruncounter. E.g. when running xruncounter alone I generally get much better results compared to running xruncounter plus a DAW.

Logically it should measure on its own. Otherwise its just a xrun display. Although if you play the way you are doing, you can have a better idea how heavy are some particular applications.
So the goal is to mark an xrun at 95% DSP?

Posted: **Fri Mar 20, 2020 10:07 pm**

thetotalchaos wrote: ↑Fri Mar 20, 2020 9:58 pm
lilith wrote: ↑Fri Mar 20, 2020 9:15 pm As far as I understand it slowly increases the DSP load and detects at which DSP load the first xruns appears. In addition it also shows the number of cycles. If your system is well configured you should reach 95% or more. What I don't understand is if a DAW that runs with higher priority in the background affects the outcome of xruncounter. E.g. when running xruncounter alone I generally get much better results compared to running xruncounter plus a DAW.
Logically it should measure on its own. Otherwise its just a xrun display. Although if you play the way you are doing, you can have a better idea how heavy are some particular applications.
So the goal is to mark an xrun at 95% DSP?

Yes, I have the feeling that the Renoise / VST DSP load is fluctuating a lot with sharp peaks and I should not expect to reach > 90% (or even much less) with running Renoise and xruncounter. A value of 95% means that all you threads are processed within 95% of the available time, so I guess that's a good value.

Posted: **Sat Mar 21, 2020 4:56 am**

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.

Posted: **Sat Mar 21, 2020 11:42 am**

tramp wrote: ↑Sat Mar 21, 2020 4:56 am 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.

Give me an example for that "CPU switches"?.
The idea for the CPU governor is to save power. And logically this will decrease the performance, incl, DSP performance.

Posted: **Sat Mar 21, 2020 12:20 pm**

thetotalchaos wrote: ↑Sat Mar 21, 2020 11:42 am Give me an example for that "CPU switches"?.

okay, here are the ones I use.

Code: Select all

intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 idle=poll

With those boot parameters added, it makes no difference any-more, to give my sound-card a higher priority.
here is a bit background knowledge about those:
https://stackoverflow.com/questions/121 ... ux-kernels

LinuxMusicians

Threadirqs kernel option with generic kernels

Re: Threadirqs kernel option with generic kernels

Re: Threadirqs kernel option with generic kernels

Re: Threadirqs kernel option with generic kernels

Re: Threadirqs kernel option with generic kernels

Re: Threadirqs kernel option with generic kernels