xruns while idling

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

delete000
Established Member
Posts: 45
Joined: Fri Dec 31, 2021 7:48 pm
Has thanked: 12 times
Been thanked: 2 times

xruns while idling

Post by delete000 »

I am investigating how close I can get to a reasonable setup by tuning an existing Ubuntu installation. Ideally, I would like to do live mixing with Mixbus, a few plugins, and a couple of live instruments. I would like to monitor instruments through Mixbus and apply fx live.

I have found latencies >20ms unworkable when e.g. playing my bass. Setting 256x2@48kHz gives 10ms which is ok. Still, I get rogue xruns while the system is idling (5% load). I could use some help tracking down the cause.

Hardware: Dell XPS 13 9300 laptop, Intel Core i7, Intel onboard wifi and graphics, external Dell USB3 monitor
Soundcard: iConnectivity iConnect 4+ (USB2)
OS: Ubuntu 20.04 (came preinstalled)
Kernel: 5.10.52-rt47-avl2
Tweaks: Installed UbuntuStudio audio package

rtcqs warns me of Spectre/Meltdown mitigation and an unused gvfs. Everything else seems to be OK, including unique IRQ for the soundcard. CPUs are set to 'performance' via UbuStu settings manager.

I've tried turning off BT & wifi - no dice. Any ideas?
User avatar
fastachee
Posts: 2
Joined: Mon Nov 22, 2021 11:17 pm
Been thanked: 1 time
Contact:

Re: xruns while idling

Post by fastachee »

I have noticed that if adb (the android debugger) is running for any reason, I have consistent xruns/clicks. Unusable until I kill it.

Not sure this applies to you, just something to keep an eye out for.
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: xruns while idling

Post by asbak »

-USB soundcard, your period "2" setting should usually be "3". If you want, frames of 128 may work for a lower latency.
-Periods of "2" have never worked for me with USB soundcards. They do work well with PCI or on-board cards.
-Some USB ports are more equal than others, some may work better than others and avoid USB hubs with USB soundcards.
-Set cpufreq to performance mode.
-Ensure you have a low-latency or preempt kernel. RT Kernel if you must, but RT kernels can cause problems with certain non-audio usage scenarios and , at least for me, performance gains were minimal to none compared to a low-latency or preempt kernel and the headaches outweighed the benefits. (Some jokers of course claim otherwise but I digress ..... )
-Stop or remove unnecessary services, and there are boatloads of them in Ubuntu. Examples include stopping cron and nuking avahi out of existence.
-Kill pulseaudio when using jack, unless you have a valid solution to pipe it through jack.
-Ensure that jack priority is around 95 in your limits.conf / audio.conf configuration files and when you start jack.
-Start jack in synchronous mode.
-Ensure your user is part of the audio group and the audio group is defined in your limits.conf and / or audio.conf files.
-Web Browsers may or may not be a potential source of xruns. I use Brave and don't appear to have problems while it's running.
-Whatever else I forgot to mention.

That should get you into somewhat working territory with minimal xruns.

There's more to it of course, depending on how your system was set up. Sometimes, installed software running in the background tries to force "solutions" on your system which can cause problems without you being aware of it.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
martibs
Established Member
Posts: 123
Joined: Mon Oct 15, 2018 7:06 pm
Location: Oslo, Norway
Has thanked: 34 times
Been thanked: 15 times

Re: xruns while idling

Post by martibs »

Have you tried the Liquorix kernel? Not sure how to install it on Ubuntu.

As mentioned by asbak, the CPU governor should be in "performance" mode. If that is already set, you might want to disable speed stepping/throttling altogether in your BIOS, to force the CPU clock into a set state.
delete000
Established Member
Posts: 45
Joined: Fri Dec 31, 2021 7:48 pm
Has thanked: 12 times
Been thanked: 2 times

Re: xruns while idling

Post by delete000 »

Thanks for all the suggestions.

- No adb / android-related stuff
- Soundcard connected directly to laptop port; no hubs
- No cron / avahi / cups / whatever daemons running
- Switched to 128x3@48kHz; this seems to have improved things a lot, but I still get rogue xruns; load is at ~8% now, 15-20% with Mixbus running
- AVLinux full RT Preempt kernel: 5.10.52-rt47-avl2. Works better than the latest Liquorix kernel in my tests so far
- CPUs are in performance mode
- pulseaudio routed through jack
- Started jackd with -S; I assume that's what synchronous mode means?
- User is part of audio group & audio group has priority 95 in limits.conf
- Switching networking on / off doesn't seem to be making a difference; not testing with browser audio anyway

Still getting xruns, though now they are much rarer (every ~10 mins) and inaudible / barely audible. But surely one can do better?

One piece of anecdotal evidence. I happened to catch an xrun while staring at top. The only process that spiked roughly at the same time was qjackctl itself.

I will see to that speed stepping/throttling BIOS setting next.
User avatar
bluzee
Established Member
Posts: 338
Joined: Mon Nov 30, 2020 11:43 pm
Has thanked: 18 times
Been thanked: 88 times

Re: xruns while idling

Post by bluzee »

I wonder if you have any real USB 2 ports on that laptop. Most now only come with USB 3. They are supposed to be backwards compatible but I don't think all chips are equal in this regard.

For playing live my preferred jack setting is 44100/32/3. The latency is low enough that I don't notice a difference from playing through regular analogue equipment. I use an fanless computer with embedded J1900 cpu and suggested configuration from Linux audio wiki. No problem with xruns. Reducing sample rate from 48000 to 44100 helps lower latency and reduce system load.
delete000
Established Member
Posts: 45
Joined: Fri Dec 31, 2021 7:48 pm
Has thanked: 12 times
Been thanked: 2 times

Re: xruns while idling

Post by delete000 »

@bluzee in this case xruns are not caused by system load. The system is literally idling. Plus I'd like to think that we can do better than 44.1kHz for low latency applications in 2022 :)
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: xruns while idling

Post by asbak »

OK glad to hear things have improved.

You shouldn't be getting random xruns while your system is just idling and doing nothing. Try starting jack and just leave things running with nothing going on. There shouldn't be xruns. If there are then something (some or other rogue process) is messing with your box.

That load with pulseaudio going through jack of 8% is slightly high but otoh I guess it's influenced by all sorts of factors. On my desktop the load's closer to around 5% when the cpu governor is set to performance. You could stop sending pulse via jack and see if it still xruns, pulse can be a nuisance.

Xruns do occasionally happen when stopping & starting audio applications, loading plugins, changing patches etc. It's just part of the experience unfortunately.

Back when I chased xrun bugs I tried exotic kernels but, at least for me, they didn't do much. Preempt or low-latency kernels are a must, but beyond that I think it's a law of diminishing returns and hassles to mess with RT kernels for audio.

I never got along with jackdbus. When you do a process listing you'll probably see that running, after you've started jack and thought you stopped it, yet jackdbus will still be running. I tend to kill mine because it's useless to me and I suspect it of being a xrun contributer, but I could be mistaken.

Jackd2 is compiled to enable jackdbus unfortunately, the only way to really get rid of it is to recompile jack yourself with jackdbus disabled. It may be a red herring like I said, but that's something I usually kill when using jack.

If you have the kxstudio repo installed, it unfortunately makes some behind the scenes changes to your system. One thing it does is to load a cadence process. I got rid of that so it doesn't keep autostarting. One less thing to suspect of causing xruns.

You may also have oss daemon process running on your system, mine had it, have no idea where it came from or why it was on there. I got rid of it.

One thing you could try I guess is, if it still randomly xruns (ie it xruns without you actively loading or unloading applications & plugins) is to set up OBS to record your desktop while you have htop or similar running. Sometimes when processes spike you get an xrun. By letting it run and capturing the desktop output you can replay the video and see when the xrun occurred and what process was running or spiking. qjackctl has a great red warning light showing when xruns occur while capturing with OBS.

Forgot to mention, obviously remember to stop pulseaudio daemons and check that there are no pulseaudio processes running before leaving the computer to see if it still xruns in jack.

And check BIOS settings for things like power saving, ramping CPU up and down etc and disable / get rid of all of those things. This isn't a sport for treehuggers. Disable any and all kinds of power-saving features in software & hardware.

One example is pulseaudio, have you noticed that "click" sound when starting tunes or whatever in Ubuntu? Ubuntu annoyingly introduced some pulseaudio power saving feature, pa suspends and then when you play a track again it wakes up and "clicks".

/etc/pulse/default.pa

and comment out
#load-module module-suspend-on-idle

Some people reckoned that threading wasn't ideal for Linux audio, ie they disabled those in BIOS / UEFI. So if you had a 4 core CPU, there'd be another 4 threads. Those can be disabled to see if it makes any difference.

Beyond that I guess try different USB ports, plug the audio interface into the USB3 port if your PC has one, check BIOS / UEFI settings for USB etc.

Qjackctl shows my system load at around 5.5% with pulseaudio going through jack, and Reaper started (with no tracks / plugins loaded).
That load you get with Mixbus seems high, unless you have plugins and things loaded?
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
User avatar
bluzee
Established Member
Posts: 338
Joined: Mon Nov 30, 2020 11:43 pm
Has thanked: 18 times
Been thanked: 88 times

Re: xruns while idling

Post by bluzee »

Hmmm... well dropping from 48000 to 44100 isn't necessary but it's a simple gain.

Only thing you are doing that I have never done is run pulseaudio with jack.

tail -f /var/log/syslog and see if you can find out what is going on with the machine while the xruns happen.
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: xruns while idling

Post by asbak »

Another thing you could try - if you have KXStudio's repo's enabled - is to enable the extras repo which may have more recent versions of alsa & jack, then run update & upgrade.

https://kx.studio/Repositories:Extras
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
delete000
Established Member
Posts: 45
Joined: Fri Dec 31, 2021 7:48 pm
Has thanked: 12 times
Been thanked: 2 times

Re: xruns while idling

Post by delete000 »

asbak wrote: Thu Jan 06, 2022 10:06 pm This isn't a sport for treehuggers.
I'll see to it that I offset my audio carbon footprint elsewhere :)

Round of tests since last update:

- Disabled all CPU scaling in BIOS; I left hyperthreading on for now
- Unplugged external monitor; since it is USB3 it is sharing that bus with the soundcard
- Disabled more services that looked useless / unrelated (whoopsie, oss, openvpn, ...)
- Obliterated pulseaudio
- Turned off all networking & bluetooth
- Uninstalled samba & sendto extensions for Nautilus (so much crap in Ubuntu!)
- Removed something called fusioninventory (?) as I noticed in the syslog it tried to contact the outside world
- No kxstudio stuff installed

Load now hovers around 0.7-0.8% in qjackctl with 128x3@48kHz. I still get rogue xruns.

Things I'll try next:

- Disable hyperthreading
- Get more recent alsa & jack
- Disable jackdbus (I'll probably compile latest stable version of jackd2 from source)

Update: as I was typing I noticed the following pop up in the syslog, roughly around the same time as an xrun: "Condition check resulted in Run anacron jobs being skipped". Yet "service --status-all" shows that both cron and anacron services are stopped. Weird.
User avatar
LAM
Established Member
Posts: 992
Joined: Thu Oct 08, 2020 3:16 pm
Has thanked: 140 times
Been thanked: 348 times

Re: xruns while idling

Post by LAM »

delete000 wrote: Fri Jan 07, 2022 3:43 pm
asbak wrote: Thu Jan 06, 2022 10:06 pm This isn't a sport for treehuggers.
I left hyperthreading on for now
That was the main cause of Xruns on my system, once disabled Xruns are much rarer.

in mix, nobody can hear your screen

asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: xruns while idling

Post by asbak »

delete000 wrote: Fri Jan 07, 2022 3:43 pm I'll see to it that I offset my audio carbon footprint elsewhere :)
That's the spirit!
Round of tests since last update:
- Disabled all CPU scaling in BIOS; I left hyperthreading on for now
OK
- Unplugged external monitor; since it is USB3 it is sharing that bus with the soundcard
Good idea, you can't be too careful. At least try rule it out.
- Disabled more services that looked useless / unrelated (whoopsie, oss, openvpn, ...)
Thanks for the reminder, I should audit the remaining services on my box again.
- Obliterated pulseaudio
- Turned off all networking & bluetooth
- Uninstalled samba & sendto extensions for Nautilus (so much crap in Ubuntu!)
Indeed
- Removed something called fusioninventory (?) as I noticed in the syslog it tried to contact the outside world
I ran a quick package & grep process search for "fusion" and found nothing on my box, but I'm on Mint 20. Perhaps this rogue process is some or other Ubuntu blessing????
- No kxstudio stuff installed
OK
Load now hovers around 0.7-0.8% in qjackctl with 128x3@48kHz. I still get rogue xruns.
That totally sucks. Just out of curiosity, have you tried just running your on-board sound card with jack, to see if it also randomly xruns?
(Just to rule out quirks with your USB card or drivers.)
I realize that the on-board card won't be of much use "in the real world" to you but at least it's something to compare against.

BTW you'll need to set periods to "2" for the on-board card, and maybe frames of 256 unless it behaves nicely with 128.

Things I'll try next:
- Disable hyperthreading
- Get more recent alsa & jack
- Disable jackdbus (I'll probably compile latest stable version of jackd2 from source)
Sounds good, we'll await your results.
Update: as I was typing I noticed the following pop up in the syslog, roughly around the same time as an xrun: "Condition check resulted in Run anacron jobs being skipped". Yet "service --status-all" shows that both cron and anacron services are stopped. Weird.
Does (as root) systemctl status cron.service show cron as being stopped or inactive?

I cannot be 100% sure but in the past I'm pretty sure some of my xruns were caused by cron housekeeping jobs which would trigger occasional high disk i/o and subsequent occasional xruns. So it may be worth tracking down any such processes which may run.

Try running iotop and monitor it for spikes in HD read/writes and see if that can be related back to xruns.

Other questions include:
- HD - is yours a spinning disk or SSD?

Further considerations:
Perhaps also look at this thread. Check out the discussion on IRQBalance. I've never bothered with modifying its settings myself (or needed to) but perhaps there's useful info.

viewtopic.php?t=13650

Video-card drivers.

I realize you've got an intel gfx chipset and it's unlikely to be a cause of problems in your particular case, and I haven't had problems with those myself, but reading through that thread reminded me about past grief with Nouveau drivers which somehow (I don't know enough about it to explain what happened) caused really poor audio performance. After switching to the proprietary nVidia drivers the xrun situation improved considerably. Whether or not Nouveau or open source nVidia drivers today still lead to poor audio performance on Linux I don't know.

USB Autosuspend, this may or may not be something worth looking into:
See this
viewtopic.php?f=27&t=23690
https://askubuntu.com/questions/185274/ ... fic-device

Lastly, more on disk i/o generating processes:
I think I was running Debian back in 2015 and there was a process called "tracker-miner-fs" which seemed to be up to no good, always generating unwelcome disk i/o workloads and presumably contributing to xruns. I don't know whether or not this is still in use or whether it's on Ubuntu. It doesn't appear to be on my Mint box.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
delete000
Established Member
Posts: 45
Joined: Fri Dec 31, 2021 7:48 pm
Has thanked: 12 times
Been thanked: 2 times

Re: xruns while idling

Post by delete000 »

Round of tests since last update:

- Disabled hyperthreading
- While in BIOS, I also disabled the touchscreen and fingerprint reader
- Removed snapd
- Removed other unnecessary VPN stuff
- Laptop has a single SSD, so no spin-down
- No rogue disk I/O processes AFAICT (no tracker-miner-fs process)

System load on qjackctl now down to 0.02%. Still getting xruns.

@asbak Thanks for the suggestion to try out the onboard card. I've started qjackctl and am waiting. No xrun so far. I'll let it idle for a couple of hours and see. If I get no xruns, it might be something to do with the USB.

What's a permanent way to disable USB autosuspend globally, preferably without installing anything? That AskUbuntu thread doesn't seem to apply to my version (20.04).
User avatar
LAM
Established Member
Posts: 992
Joined: Thu Oct 08, 2020 3:16 pm
Has thanked: 140 times
Been thanked: 348 times

Re: xruns while idling

Post by LAM »

delete000 wrote: Fri Jan 07, 2022 6:57 pm What's a permanent way to disable USB autosuspend globally, preferably without installing anything? That AskUbuntu thread doesn't seem to apply to my version (20.04).
https://askubuntu.com/a/1161074

Try with this:

Code: Select all

GRUB_CMDLINE_LINUX="usbcore.autosuspend=-1"

in mix, nobody can hear your screen

Post Reply