Standard test needed to benchmark XRUNs
Moderators: MattKingUSA, khz
-
- 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
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/
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/
- 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
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$
Re: Standard test needed to benchmark XRUNs
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?
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?
-
- 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
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.
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.
- 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
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:
Now with Reaper open, but in idle (i.e. track is stopped)
And with Reaper playing the track:
@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
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
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.
-
- 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
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?
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?
- 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
If it comes from Jack it's strongly averaged (I will look for the exact number, I discussed this with JackWinter last year).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?
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:
Last edited by lilith on Wed May 01, 2019 9:54 pm, edited 1 time in total.
-
- 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
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
- 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
I think this is because the dsp load in Reaper was high and fluctuating in the beginning when the ,3rd xrun appeared.merlyn wrote: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.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
-
- 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
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
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
- 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
Is the jack processing thread still running with a higher real-time priority than any reaper threads?lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
(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 )
- 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
I´ll make some tests again and also carefully re-read this thread again: viewtopic.php?f=27&t=19276&hilit=xruns+but+whyraboof wrote:Is the jack processing thread still running with a higher real-time priority than any reaper threads?lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
(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 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?
- 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
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.raboof wrote:Is the jack processing thread still running with a higher real-time priority than any reaper threads?lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
(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 )
- 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
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?lilith wrote: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.raboof wrote:Is the jack processing thread still running with a higher real-time priority than any reaper threads?lilith wrote:if anything with RT priority is running in the backgound (e.g. reaper) it can occur much earlier.
(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 )
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.