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

Re: xruns while idling

Post by delete000 »

LAM wrote: Fri Jan 07, 2022 7:20 pm Try with this:

Code: Select all

GRUB_CMDLINE_LINUX="usbcore.autosuspend=-1"
Done. Still get xruns idling.

I installed iotop and will try to record the screen with that and htop running to see if something pops up when an xrun occurs.
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 »

This is from iConnectivity support website....
We have received reports that many audio interfaces are having problems with some modern computers equipped with USB-C ports. The reason for this is that it seems that there is currently a bug in one of the Intel USB controller chips inside these computers that means many digital audio interfaces will not work correctly and will produce distorted sound or random disconnects when plugged into them. Note that this is not just a problem with our interfaces, it affects many interfaces from other companies too.

Our investigations indicate that there may be problems with the USB subsystems on the following machines (and possibly several others we have not yet tested):

Razer Blade laptops
Razer Core external GPU enclosure
Apple mid-2018 Mac Mini
Apple mid-2018 MacBook

If you have one of these machines, or another computer equipped with USB-C ports that seems to be exhibiting problems with your iConnectivity interface, there are several workarounds you can try:

Most USB-C computers also have legacy USB-A ports, and in some cases these legacy USB-A ports are internally connected to a different USB controller chip that does not exhibit this buggy behavior. So the first thing to try is simply to connect your interface to one of the USB-A ports instead of a USB-C port. On many computers (for example the Razer Blade 14" 2017 edition) this will solve the issue immediately.

However some computers do not feature legacy USB-A ports, and others (such as the 2018 Apple Mac Mini) may have their legacy ports internally connected to the same problematic USB controller chip. In these cases the best workaround we have found is to attach an external Thunderbolt 3 hub to one the computer's USB-C ports, and then attach your iConnectivity interface to one of the USB-A ports on the Thunderbolt hub. Note that most common "USB-C hubs" will not work - to work correctly the hub must be fully Thunderbolt 3 compatible. You can recognize a Thunderbolt 3 hub by checking that the following features are listed:

The description specifically says that is Thunderbolt 3
The USB-C connector shows a small lightning bolt symbol
It is capable of 40GB/s data transfer
The display port supports 60 Hz operation

Note that Thunderbolt 3 hubs are usually also considerably more expensive than standard USB-C hubs - expect to pay around $150 or higher. We recommend Thunderbolt 3 hubs from CalDigit - we have tested these and they work very well, and seem to be well constructed. They also include an Ethernet port which is very useful if you also intend to use RTP-MIDI over Ethernet, which is standard in many of our interfaces.
As mentioned it could be an issue with a buggy chipset. You have stripped your machine down far beyond what should be necessary for 48000/128/3.
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 »

Yeah it's a weird one, as bluzee mentions it shouldn't typically be necessary to go to the lengths you're going to. It's as if there's some rogue process that we're missing. Maybe there are more USB or autosuspend or power saving settings somewhere that require attention.

I wonder how simple it would be to generate artificial mouse movements, ie have a process automagically move the mouse cursor around the screen while you're away, to keep up the semblance of "user activity", just in case there is some kind of suspend or power saving event happening when the system decides that the user is away.

Also just to be clear, during the last batch of tests was it xrunning with the internal card or the USB card, or is it xrunning on both?
I don't think there'd be much point setting things lower than 2x256@48K on the internal card.
Once one starts pumping real workloads through you need as much of a safety margin as you can afford.

Maybe also check things like your screensaver, also the "turn off monitor" in power management settings etc. I just came back to my desktop and it had 1000's of xruns while I was away for a few hours, probably caused by something related to "turn off monitor" or the screensaver, because it doesn't xrun while I'm actively using the system. In my case it doesn't matter if it xruns while not in use, so it's debateable if it's worth my while to disable the monitor suspend & screensaver to see if that makes a difference.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
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 can try is to boot your system from an AVLinux USB stick into Live Mode and to see if it still xruns.
That may provide a hint whether you're dealing with a hardware problem or whether the Ubuntu 20 install is still doing something annoying.

If the random xruns at idle stop occurring when booted in AVLinux then at least we know that it's not likely to be a hardware issue.
It if still xruns.... well..... then we're back to square one. :mrgreen:

You could try it both on the internal card and the USB card.
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 »

Here's a screen grab of iotop and htop as an xrun happens:
https://ufile.io/c1zbwf9k

The only thing that I see happening is a jackdbus process. Note that this xrun happened a couple of minutes after I started recording, so nothing is supposed to be going to sleep. I have disabled screensavers and monitor sleep mode anyway. After taking this vid, I also run tests having killed jackdbus. Still getting xruns.

@bluzee Thanks for tracking down that Intel USB C glitch report. I don't have a Thunderbolt 3 adapter, but my external monitor works as one. I plugged the soundcard into the monitor USB port. Still get xruns.

@asbak I have yet to get a single xrun using the onboard card. And I used reasonable settings for it, i.e. 256x2@48k as you suggest. So at least there's that clue.

Next steps:
- AVLinux MX USB boot
- I do have a USB C -> Thunderbolt 3 -> FW800 -> FW400 chain of adapters and a RME Fireface 400. Miraculously, I have succeeded getting audio out of that mess but haven't done thorough testing. I'd much rather use that soundcard if possible anyway, so I'll give that setup a shot as well, though I have very little hope it will be stable.
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 that's interesting, no xruns with the on-board card. So the basic system tuning is already quite good as we suspected.
It would be interesting to see what happens under AVLinux and whether the USB Audio xruns persist.


Based on what we've found so far, there could be something flaky with one or more of the
- USB ports
- USB audio driver
- USB port power management or
- USB audio hardware?

Or it is something else we're missing?????


Some additional things to try:

Disable jackdbus:
sudo su -
cd /usr/share/dbus-1/services/; mkdir old; mv org.jackaudio.service old
- Reboot
- jackdbus should be deactivated, to reactivate - should you need it - just reverse the process

USB Port Autosuspend:
- LAM suggested the autosuspend string earlier, here's an alternative method.
- Sometimes methods to control the system get deprecated in favor of new methods, it's not always clear (unless one remains up to date with all of it - which I'm not) on what actually still works and what doesn't.
- In this case we change the setting of power/control from "auto" to "on" to hopefully disable USB autospend.


- !!NOTE: Obviously check the commands first and adjust where necessary for your system before blindly running them
- !!Don't blame me if I screwed up and it breaks your system, LOL :mrgreen:

- Guess or derive the vendor / manufacturer name of the USB Soundcard
lsusb

- Alternatively check for it with
udevadm info --export-db | egrep "ID_VENDOR|ID_MODEL" | less

- Set vendor and devices path variables
vendor=edirol # [!!change this value for your particular card!!]
mydevices=/sys/bus/usb/devices/

- !!The cut values to locate the relevant "usbX/N-N" entry under /sys/bus/usb/devices/ (in my case 5,6) for your USB soundcard may need to be adjusted for your particular system!!
- !!Find the cut values!!: vendor=<your vendorname>; udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH

- Identify USB Soundcard & Port
cd $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)
pwd
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/manufacturer
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/idVendor
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/idProduct

- Power/Control is probably set to "auto" to enable suspend, set to "on" to disable suspend
- Check current value of USB suspend "power/control"
sudo su -
vendor=edirol # !!change this value for your particular card!!
mydevices=/sys/bus/usb/devices/
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/power/control

- Disable autosuspend
echo "on" > $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/power/control

- Check new status of control for soundcard
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/manufacturer
cat $mydevices$(udevadm info --export-db | grep -B15 -i $vendor | grep -B10 BUSNUM | grep DEVPATH | cut -f 5,6 -d /)/power/control

If it is now "on", USB autosuspend is now hopefully disabled for that card.
Then test again :)

PS
That setting won't persist following a reboot, so if you want to make it permanent you'll need to write a script or create a udev rule or something.
A udev rule would be nicer but I couldn't get it to work for some reason.
Last edited by asbak on Sat Jan 08, 2022 4:54 pm, edited 4 times in total.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
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 »

And yet one other thing to try - for what it's worth - is to disable wireless scanning.
I think (I hope?) it is disabled when stopping network manager

Disable Wireless Scanning
systemctl stop network-manager.service
Last edited by asbak on Sat Jan 08, 2022 4:55 pm, edited 1 time in total.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: xruns while idling

Post by merlyn »

I don't use a USB interface myself, but something that I've seen in other threads here is using a buffer size that is a multiple of the numbers of samples in 1ms. e.g. at 48kHz try a buffer of 48, 96, or 144.

These values don't appear in JACK dropdowns, so you type them in.

The idea is that USB audio uses packets -- USB 2.0 sends 8 packets per millisecond, so doing what I described above means there is the same number of samples in each packet.

You have my sympathy as your hardware looks good and it should work xrun free. I recently put together a good system and it works xrun free. I've left it on overnight and got no xruns.
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 »

From the video, Simple Screen Recorder performs a DISK WRITE just before the xrun occurs.
Whether this is of significance or just a coincidence I don't know. 00:14 on the clip

That's followed by a "jackdbus auto" event and then the xrun occurs immediately thereafter.
It may be coincidence, it may be significant. Again, I don't know.


jbd2
The other thing I noticed from iotop was a jbd2 event, perhaps also not significant but a couple of things to consider:
- I think (could be mistaken?) that newly "quick" formatted disks are properly-formatted by jbd2 as the computer runs, so over time there will be more jbd2 activity until such time as the whole disk is really formatted. More I/O obviously means more strain on the system. Eventually jbd2 will format the whole thing and the load should lighten.
- jbd2 itself may not be an issue but may point toward other issues....... which relate to jbd2

Snapd
Another thing that may or may not be worth looking into on Ubu 20 is snapd. Snapd is purposely disabled by the developers of Mint due to concerns over privacy and independence, but I think it comes standard with Ubuntu?

Snapd may or may not be causing system strain & overhead. Another candidate for disabling or uninstalling perhaps on Ubuntu 20??

Comparative system at home
For comparison I loaded Mint 20.2 on a Lenovo T460 i5 laptop.
jack 3x128@48K using an Edirol UA-25 USB audio interface, no special tuning beyond the basics we already discussed, using a standard low-latency kernel.
Load displayed in qjackctl with pulse-audio piped through jack & Reaper running while idling is between 10% and 15%.
Not seeing any xruns.
Last edited by asbak on Sat Jan 08, 2022 5:23 pm, edited 1 time in total.
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 »

I left the the FF400 running (2x128@48k) for the last 3+ hours, connected through that Thunderbolt 3 -> Thunderbolt 2 -> Firewire 800 -> Firewire 400 contraption. Against all odds, zero xruns so far. Wifi on, pulseaudio routed through jack, external monitor plugged in, cron & co all left running. And 5ms latency!

Note that the firewire card goes through the same USB-C port as the USB card did. So I have a situation where a USB port does not work properly for USB audio traffic but works for firewire. This looks like a manifestation of the USB chip issue @bluzee found. The quoted text seems to suggest that packaging the audio stream as Thunderbolt 3 traffic to leave the board circumvents that issue, and this also seems to be my case.

I guess I'll keep testing the present setup and relegate the USB card back to its intended use (iPad). I'll report findings later, maybe this rinky-dink patchwork holds up well and might be of interest to others.

EDIT :: @asbak I suspected snapd too, so I removed it. I also disabled jackdbus in further tests, didn't make a difference. And thanks for testing & reporting the results with the Thinkpad. My old laptop was a Thinkpad T500 and I used to play live with that (Hydrogen+Ardour) back in 2012, though back then latency was less of an issue (no live instrument playing).
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 »

Nice, congrats to bluzee for tracking that down :)
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 »

Update after ~2 weeks.

- Virtually no xruns with my FW interface plugged in as a Thunderbolt 3 device into a USB-C port. Iterating this as it's hard for me to believe.
- There's definitely something going on with the USB bus. In fact it seems that the *order* in which devices are plugged in affects the audio.
- If the order is respected, then even Digitakt via Overwitch plugged into the USB-C monitor seems to work fine. So video, Digitakt audio, and power all go through one USB-C port, FW audio to soundcard through the other USB-C port. Everyone's happy.
- If the order is not respected, audio comes through bit-crushed.
- I can only satisfy the USB controller by trial and error. Usually unplugging the monitor and plugging it back in does the trick.
- Pulseaudio is garbage on this setup. Removed it altogether.
- Loaded up a bunch of plugins, long audio files etc onto a Mixbus project. CPU goes up to 50% max with 128 frames / 5ms @ 48K. I wonder if I can push it to 64 frames.
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 run a full rack of guitar processing on my old 2Ghz dual core laptop at 64/3 no problem. At 32/3 I start getting the odd random xrun. Nothing that is perceptible over the thunder coming out of the bass players rig.
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 »

I tried 64/3 but my setup wouldn't have it. Xrun galore. I'm happy to stick to 128x2 for now.

OTOH, my setup is now almost rock solid. I keep Mixbus running permanently without issues, except some curious glitch that forces me to restart once a week. Something seems to recur every Friday night.

And there's definitely some USB / Thunderbolt bus - network interference going on. Output of

Code: Select all

lsusb -v
contains words like "wireless" and "bluetooth". Ugh. Why?? I'm tempted to just disable both in BIOS. Maybe once my setup has crystallized to the point where I'm sure I don't want to install anything ever again.
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 »

Wifi and Bluetooth are constantly polling looking for signals or devices to connect to. This can be a problem. I think just stopping the appropriate services for these is sufficient, however if you don't ever use them then by all means turn them off in BIOS.

Some have written scripts to stop all unnecessary services prior to starting an audio session as well as restart them once done.
Post Reply