Standard test needed to benchmark XRUNs

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Post Reply
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: Standard test needed to benchmark XRUNs

Post by gimmeapill »

Thanks for double checking.
So it looks like another configuration setting that could be detected better (although this is really a corner case) - at least we know about it.

On my side I didn't have much time for more testing (or to look at the jack API), but I created the project on github:
https://github.com/Gimmeapill/xruncounter

I tried to make it clear that I am not the author and chose GPLv3 licensing.
(@Tramp: if you see something you're not happy with, please shout).
Next I'll probably write a bit of documentation to sum up what was discussed here.
And since I cannot really maintain it: if anyone feels like taking over please do not hesitate.

Here's also a pkgbuild for those on Arch:
https://aur.archlinux.org/packages/xruncounter-git/
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

Really strange: Sometimes I get xruns at already 20% and then 10 times or so at 98% again. Can pulseaudio which is running via the jack bridge cause such xruns at very low DSP loads? During the first test where the first xrun happend at 25% pulse was running.

Code: Select all

marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 25.647621
Xrun 2 at DSP load 25.647621
Xrun 3 at DSP load 28.733669
^C signal 2 received, exiting ...
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.538666
in complete 1 Xruns in 43227 circles
first Xrun happen at DSP load 98.538666 circle 43224
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 80.688637
Xrun 2 at DSP load 98.467209
in complete 2 Xruns in 43943 circles
first Xrun happen at DSP load 80.688637 circle 36837
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.682068
in complete 1 Xruns in 43696 circles
first Xrun happen at DSP load 98.682068 circle 43694
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 90.428696
Xrun 2 at DSP load 98.216171
in complete 2 Xruns in 42323 circles
first Xrun happen at DSP load 90.428696 circle 41451
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.020401
in complete 1 Xruns in 40515 circles
first Xrun happen at DSP load 98.020401 circle 40512
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.935867
in complete 1 Xruns in 40646 circles
first Xrun happen at DSP load 98.935867 circle 40644
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 96.283813
in complete 1 Xruns in 38898 circles
first Xrun happen at DSP load 96.283813 circle 38898
marco@fox:~/src$ 
Spanner
Established Member
Posts: 76
Joined: Mon Mar 10, 2014 8:18 pm
Been thanked: 2 times

Re: Standard test needed to benchmark XRUNs

Post by Spanner »

I have a USB interface:
USB-Audio - USB Audio CODEC
Burr-Brown from TI USB Audio CODEC at usb-0000:00:12.0-3, full speed

I was running set at:
periods = 3
buffersize = 256 (or 512)
block latency was reported by Cadence to be around 5ms (or 10ms)
I held this setting because I thought that 3 periods was somehow better or necessary for USB audio interfaces. I thought maybe I could do better.


I downloaded and compiled xruncounter (thank you tramp! et al.) and then experimented with dropping periods down to 2 and altering buffersize:

periods = 2
buffersize = 192
samplerate = 48000
block latency was reported by Cadence to be 4ms


Testing over several iterations...

./xruncounter
first Xrun happen at DSP load 97.305107 circle 17107

./xruncounter
first Xrun happen at DSP load 99.298500 circle 17164

./xruncounter
first Xrun happen at DSP load 99.975204 circle 17519

./xruncounter
first Xrun happen at DSP load 99.392029 circle 17299

./xruncounter
first Xrun happen at DSP load 99.679459 circle 17608


Next, tried buffersize = 288

periods = 2
buffersize = 288
samplerate = 48000
block latency was reported by Cadence to be 6ms


Again, testing over several iterations...

./xruncounter
first Xrun happen at DSP load 99.576996 circle 26257

./xruncounter
first Xrun happen at DSP load 99.503143 circle 26250

./xruncounter
first Xrun happen at DSP load 99.217041 circle 26227

./xruncounter
first Xrun happen at DSP load 99.275375 circle 26182

./xruncounter
first Xrun happen at DSP load 99.476608 circle 26235


It looks to me as if buffersize = 288 would be the wiser choice for me to run at.


Ideas?
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

Re: Standard test needed to benchmark XRUNs

Post by Musicteacher »

As far as I have understood: The higher the buffer size, the less xruns. So if you can live with a high latency, why not use 288 bit buffer? I could not, as I use virtual instruments.

Sudden very bad values could be because of pulse (I don't have pulse sink running, I can't say), but could be because of
a) non-constant cpu clock speed
b) c-states higher than 1

As I said in the other thread: xruncounter is a great tool to get started. But you will have to test your system with real load (multiple tracks with plugins, for instance) to drive all cores of you cpu. It does not help you if you get great values of xruncounter and then with real load your cpu gets hot and throttled and you get big cracks!

All depends on what you need the machine for (live playing or mixing). When mixing only, latency is not much of an issue, you can use high buffer sizes.
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

It's not pulseaudio related. After it was fine for several days, I again get a lot of xruns with an older Reaper project that played well before.

@tramp: What is the integration time of your xruncounter script? Can it be that spikes in CPU load are overseen? E.g. there's a spike that reaches >99% but the integral is only 30% as measured by xruncounter? Otherwise I can't explain why I get sometimes xruns at very very low CPU loads (~30%), which makes no sense to me. If the script is running alone the first xrun occurs at >90% normally, but if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier. For instance when Reaper is in idle mode first xrun occurs at 65% and when the track is playing at 30% .... If anyone knows how I can find out what's responsible for this it would be great.

Here are two runs with all DAWs closed:

Code: Select all

marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 95.685410
^C signal 2 received, exiting ...
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 97.598068
in complete 1 Xruns in 45186 circles
first Xrun happen at DSP load 97.598068 circle 45181
Now with Reaper open, but in idle (i.e. track is stopped)

Code: Select all

marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 62.780342
Xrun 2 at DSP load 64.084518
Xrun 3 at DSP load 65.989319
Xrun 4 at DSP load 65.989319
Xrun 5 at DSP load 68.181633
Xrun 6 at DSP load 69.106560
Xrun 7 at DSP load 69.183929
Xrun 8 at DSP load 69.327797
Xrun 9 at DSP load 75.632545
Xrun 10 at DSP load 85.843857
Xrun 11 at DSP load 88.818085
Xrun 12 at DSP load 88.818085
Xrun 13 at DSP load 93.207947
Xrun 14 at DSP load 94.876694
Xrun 15 at DSP load 94.992889
Xrun 16 at DSP load 94.992889
Xrun 17 at DSP load 96.660477
in complete 17 Xruns in 32705 circles
first Xrun happen at DSP load 62.780342 circle 28268
And with Reaper playing the track:

Code: Select all

./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 46.874947
Xrun 2 at DSP load 54.452980
Xrun 3 at DSP load 54.452980
Xrun 4 at DSP load 49.535583
Xrun 5 at DSP load 48.074806
Xrun 6 at DSP load 47.560131
Xrun 7 at DSP load 45.085487
Xrun 8 at DSP load 47.813301
Xrun 9 at DSP load 47.813301
Xrun 10 at DSP load 46.581383
Xrun 11 at DSP load 46.581383
Xrun 12 at DSP load 46.581383
Xrun 13 at DSP load 77.270401
Xrun 14 at DSP load 72.430992
Xrun 15 at DSP load 72.430992
Xrun 16 at DSP load 75.337296
Xrun 17 at DSP load 95.307411
Xrun 18 at DSP load 69.708252
Xrun 19 at DSP load 55.445038
Xrun 20 at DSP load 57.432655
Xrun 21 at DSP load 57.432655
Xrun 22 at DSP load 57.432655
Xrun 23 at DSP load 50.161781
Xrun 24 at DSP load 49.249073
Xrun 25 at DSP load 49.249073
^C signal 2 received, exiting ...
lilith wrote:Really strange: Sometimes I get xruns at already 20% and then 10 times or so at 98% again. Can pulseaudio which is running via the jack bridge cause such xruns at very low DSP loads? During the first test where the first xrun happend at 25% pulse was running.

Code: Select all

marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 25.647621
Xrun 2 at DSP load 25.647621
Xrun 3 at DSP load 28.733669
^C signal 2 received, exiting ...
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.538666
in complete 1 Xruns in 43227 circles
first Xrun happen at DSP load 98.538666 circle 43224
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 80.688637
Xrun 2 at DSP load 98.467209
in complete 2 Xruns in 43943 circles
first Xrun happen at DSP load 80.688637 circle 36837
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.682068
in complete 1 Xruns in 43696 circles
first Xrun happen at DSP load 98.682068 circle 43694
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 90.428696
Xrun 2 at DSP load 98.216171
in complete 2 Xruns in 42323 circles
first Xrun happen at DSP load 90.428696 circle 41451
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.020401
in complete 1 Xruns in 40515 circles
first Xrun happen at DSP load 98.020401 circle 40512
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 98.935867
in complete 1 Xruns in 40646 circles
first Xrun happen at DSP load 98.935867 circle 40644
marco@fox:~/src$ ./xruncounter 
Samplerate 48000 
Buffersize is 528 
jack running with realtime priority
Xrun 1 at DSP load 96.283813
in complete 1 Xruns in 38898 circles
first Xrun happen at DSP load 96.283813 circle 38898
marco@fox:~/src$ 
Last edited by lilith on Wed May 01, 2019 9:32 pm, edited 1 time in total.
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: Standard test needed to benchmark XRUNs

Post by merlyn »

You might like to know there's a new version here :

https://github.com/Gimmeapill/xruncounter

I've looked at the xruncounter code and there is no averaging or integration. The DSP load comes from JACK.

Have you looked at what your CPU load is doing during your tests with htop or similar? The question would be is it the same value that xruncounter reports?
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

merlyn wrote:You might like to know there's a new version here :

https://github.com/Gimmeapill/xruncounter

I've looked at the xruncounter code and there is no averaging or integration. The DSP load comes from JACK.

Have you looked at what your CPU load is doing during your tests with htop or similar? The question would be is it the same value that xruncounter reports?
If it comes from Jack it's strongly averaged (I will look for the exact number, I discussed this with JackWinter last year).
I increased the buffer size to 1056 samples, which helped a bit. But still I get the first xrun at ~40%. With Alsa it seems to be better. I will do some tests the next days and check the new version (time for bed now). Thanks for helping!

Here 's a screenshot with the numbers:

Image
Last edited by lilith on Wed May 01, 2019 9:54 pm, edited 1 time in total.
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

edit
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: Standard test needed to benchmark XRUNs

Post by merlyn »

Code: Select all

Xrun 2 at DSP load 54.452980
Xrun 3 at DSP load 54.452980
Xrun 4 at DSP load 49.535583
Xrun 5 at DSP load 48.074806
Xrun 6 at DSP load 47.560131
Xrun 7 at DSP load 45.085487
DSP load going backwards means there is something wrong. I looked into this and decided that it's JACK, not xruncounter. I want to figure it out when I get some time.
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

merlyn wrote:

Code: Select all

Xrun 2 at DSP load 54.452980
Xrun 3 at DSP load 54.452980
Xrun 4 at DSP load 49.535583
Xrun 5 at DSP load 48.074806
Xrun 6 at DSP load 47.560131
Xrun 7 at DSP load 45.085487
DSP load going backwards means there is something wrong. I looked into this and decided that it's JACK, not xruncounter. I want to figure it out when I get some time.
I think this is because the dsp load in Reaper was high and fluctuating in the beginning when the ,3rd xrun appeared.
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: Standard test needed to benchmark XRUNs

Post by gimmeapill »

One idea here: Try to get back to "standard" buffersizes, so something like 512 instead of 528.
I don't know about Reaper but this seems to cause problems with some applications (on my setup, Ardour didn't like it for example)

By the way, if anyone want to take over the github project or just be added as collaborator, please shout ;-)
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by raboof »

lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
Is the jack processing thread still running with a higher real-time priority than any reaper threads?

(I guess something like "ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd" should help figuring this out, though it'd be good to document this on the wiki somewhere ;) )
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

raboof wrote:
lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
Is the jack processing thread still running with a higher real-time priority than any reaper threads?

(I guess something like "ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd" should help figuring this out, though it'd be good to document this on the wiki somewhere ;) )
I´ll make some tests again and also carefully re-read this thread again: viewtopic.php?f=27&t=19276&hilit=xruns+but+why

I also observed two days ago, that I get xruns, when I watch a video (e.g. youtube) in fullsize. Normal size is not a problem. I´m using the standard Debian kernel again, not the RT kernel. Maybe that´s part of the problem?
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by lilith »

raboof wrote:
lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
Is the jack processing thread still running with a higher real-time priority than any reaper threads?

(I guess something like "ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd" should help figuring this out, though it'd be good to document this on the wiki somewhere ;) )
What do you mean with "Is the jack processing thread still running with a higher real-time priority than any reaper threads? "? Jack has to run, otherwise I can´t run the xruncounter script.
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Standard test needed to benchmark XRUNs

Post by raboof »

lilith wrote:
raboof wrote:
lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
Is the jack processing thread still running with a higher real-time priority than any reaper threads?

(I guess something like "ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd" should help figuring this out, though it'd be good to document this on the wiki somewhere ;) )
What do you mean with "Is the jack processing thread still running with a higher real-time priority than any reaper threads? "? Jack has to run, otherwise I can´t run the xruncounter script.
Indeed obviously Jack is running. What I was asking is: what is the priority of the jack processing thread? And is it higher than the reaper thread?

If non-RT reaper threads have higher priority than the jack processing thread, those reaper threads could prevent the jack processing thread from running, causing xruns.
Post Reply