xruns while idling

[delete000]

Wifi and Bluetooth are constantly polling looking for signals or devices to connect to.

Yeah, what's weird is it seems some process / service tries to access Wifi / BT even though both are turned off in Ubuntu. I suspect this pings the hardware, which, unfortunately, means throwing the USB bus out of whack (exactly once a week, weirdly). OTOH, restarting once a week might not be too bad an idea either.

I'll give turning off network+BT in BIOS a shot, just to verify.

[asbak]

@delete000

Out of curiosity, could you please share the brands & models for the working Thunderbolt 3 to Thunderbolt 2 and the TB2 to Firewire chain?
Which make/model adapters do you have working on Linux?

Thunderbolt 3 to Thunderbolt 2
Thunderbolt to Firewire 800

[delete000]

@asbak Sure:

1. Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter
2. Apple Thunderbolt 2 to FireWire 800 Adapter
3. Generic FireWire 800 (IEEE 1394b) 9-pin to 6-pin cable

I went with Apple because I saw a video of someone using them with various FW peripherals on Win 10. I vaguely remember this person claiming that no other adaptors worked properly, but I doubt that. It's just wires. If the right wire is soldered to the right lead, it should work the same.

[asbak]

Thank you kindly sir.

There may be some truth to claims that some adapters will / won't work or that some will work better than others but especially nowadays there wouldn't be all that many people evaluating them so it is hard to really know. It is good to know that these work well because alternative options such as Startech are prohibitively expensive.

By the way I found some info on firewire PCI-e cards for desktops elsewhere and the pecking order of goodness appeared to be

1) LSI FW533E or FW643E
2) Texas Instruments XIO2213B
3) VIA VT6315 (preferable), possibly also the VT6307, VT6308 (less preferable)

[12strings2hands]

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.

Reading this cause I'm bored, but...why are you using Jack? Paul Davis, who wrote Jack and also much of Mixbus, says ALSA is fine unless you have special needs that Jack can solve.

[delete000]

Reading this cause I'm bored, but...why are you using Jack? Paul Davis, who wrote Jack and also much of Mixbus, says ALSA is fine unless you have special needs that Jack can solve.

Does ALSA do firewire?

[asbak]

Does ALSA do firewire?

Afaik the old drivers support two channels (at least that's what I seemed to get when I tried it in pulse, jack wasn't working), haven't tested with more recent drivers yet.

Update:
Appears to work with new ALSA drivers, provided drivers exist for one's particular audio interface. (Using your suggested adapter chain.)

[delete000]

In case anyone arrives to this end of the Internet, I believe I have found what the issue was. It seems like the xruns were caused by sync issues when the soundcard is synced to an external clock source. Setting the card to master, my setup now idles for days without any xruns. Thanks to everyone who helped me troubleshoot this for their suggestions!

[delete000]

While I have been able to reduce the occurrence to roughly once per week, the mystery persists.

I have tried a couple more things:

• Plugged the interface and monitor into a UPS. We do get power spikes where I live, so it seemed this might help. No dice.
• Sometimes, after the system has idled for multiple days, I notice the following pattern in qjackctl: the number of xruns reported outside the parentheses stays fixed to a small value, while the number inside the parentheses grows continuously to many thousands. When this happens, I get no sound through my interface and also - curiously - all network interfaces disappear: ifconfig shows only loopback.

Stopping and restarting qjackctl restores sound, but the output comes out bit crushed. Disconnecting the USB C cable going to the external monitor and reconnecting it eliminates the bit crushing and I get sound back ok (but not the network!). This is some seriously spooky stuff....

[autostatic]

Did you try rtirq-init? Haven't read any suggestions yet to prioritize your USB ports. To prioritize your USB ports with rtirq-init make sure the line with RTIRQ_NAME_LIST in /etc/default/rtirq looks like this:

Code: Select all

RTIRQ_NAME_LIST="xhci"

Then restart rtirq with systemctl restart rtirq-init. Now your USB port IRQ's have priority over other IRQ's and can make them wait until it has finished itself (preemption).

[delete000]

Thanks for the suggestion @autostatic. Here's how that line looks currently:

Code: Select all

RTIRQ_NAME_LIST="snd usb i8042"

I suppose I could include xhci between snd and usb?

[autostatic]

I would just replace the current values with just xhci. I've worked on the same model XPS and from what I remember it only had USB3 ports. I'll check the backup I have from that machine, maybe I backed up /etc/default/rtirq from that machine too.

Regarding the current values, snd is for prioritizing onboard stuff, usb doesn't do much anymore these days on more modern machines and if you'd like a keyboard or mouse without xruns you could opt for leaving i8042 in there.

Edit: here's the line from the backup I made from the XPS I owned:

Code: Select all

RTIRQ_NAME_LIST="xhci usb3"

So usb3 is in there, apparently my XPS was somewhat older than yours, I see you have a 9300 from 2020, mine was a 9360 from 2016. You could check with grep usb /proc/interrupts if you still have USB2 ports that load the ehci_hcd driver and add either ehci or usb to the RTIRQ_NAME_LIST variable.

[delete000]

I would just replace the current values with just xhci. I've worked on the same model XPS and from what I remember it only had USB3 ports. I'll check the backup I have from that machine, maybe I backed up /etc/default/rtirq from that machine too.

Regarding the current values, snd is for prioritizing onboard stuff, usb doesn't do much anymore these days on more modern machines and if you'd like a keyboard or mouse without xruns you could opt for leaving i8042 in there.

Edit: here's the line from the backup I made from the XPS I owned:

Code: Select all

RTIRQ_NAME_LIST="xhci usb3"

So usb3 is in there, apparently my XPS was somewhat older than yours, I see you have a 9300 from 2020, mine was a 9360 from 2016. You could check with grep usb /proc/interrupts if you still have USB2 ports that load the ehci_hcd driver and add either ehci or usb to the RTIRQ_NAME_LIST variable.

No dice. Btw, I am now on AVL-MXE and can boot with either sysvinit or systemd. Same behaviour with both.

[delete000]

Some more clues. When the xrun counter starts incrementing continuously, the messages window is flooded with:

Code: Select all

JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = mixbus was not finished, state = Triggered

Pretty cryptic. I found a thread describing a similar issue in a very different context:
https://github.com/m-r-s/hearingaid-pro ... -416225008
I'm wondering whether this might be related, since the jack errors often coincide with network glitches. Any ideas?