Xruns keeps coming for no apparent reason

#1

Hi there,

I’ve been using Ardour for two years now, until this day without troubles.

Today, however, I’m facing a very strange issue which is making the program unusable: Xruns keeps coming out of nowhere, be I’m recording, listening to tracks or even doing nothing.

Before I continue, I should inform that I’m running Ardour in Ubuntu 18.04 with 8GB of RAM. I use Jack and have a Scarlett 2i2 audio interface.

In Jack, my settings are:

Sample Rate: 44100
Frames/Period: 256
Periods/Buffer: 2

I’ve never had this problem before since I work with this DAW, so I wonder how can this be a settings related issue.

Also, after the Xruns began to appear, the playhead started to behave erraticly, stopping an moving backwards randomly.

The first place I went to seek any information was Jack’s logs. I’ve found these messages there:

21:52:55.820 XRUN callback (795).
Sun Aug 25 21:52:55 2019: ERROR: JackEngine::XRun: client = ardour was not finished, state = Running
Sun Aug 25 21:52:55 2019: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error

When I went back to Ardour, I’ve noticed that the “Audio” information in the status bar didn’t match Jack’s settings. Shouldn’t it?

screenshot_17
screenshot_17.png1916×1077 217 KB

Thanks for reading and I’m hoping anyone can clarify this to me.

Pierre

Xrun keep coming when using VSTs
#2

USB devices usually require a realtime-kernel (preempt-rt) and some system tweaking (rtirq) to reliably run at a buffersize 256 or lower.

Also see https://www.linuxmusicians.com/viewtopic.php?f=47&t=10707

#3

Hi @x42,

My kernel is low-latency, as you can see below. Is this the same thing as realtime?

Linux pdechery-Inspiron-3647 4.15.0-58-lowlatency #64-Ubuntu SMP PREEMPT Tue Aug 6 12:17:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I don’t mind changing the buffersize as needed but I wonder how the problem didn’t happen before all this time. And I use Ardour pretty intensively.

I will read carefully the link you gave, thank you.

#4

Nope. Lowlatency configuration only gets you only halfway there. It doesn’t allow to preempt kernel drivers.

In most cases the issue is that some other device hogs the bus for a long time and the USB device won’t be able to deliver/receive audio. That could be some other USB device, or WiFi, or graphics.

256 * 3/ 48k is borderline to work with a default (non rt-preemtive) kernel, but that highly depends on your CPU and hardware (mainboard, USB chipset,…). Some treatise on that subject: http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ and some long but good explanation: https://www.youtube.com/watch?v=GUsLLEkswzE

If you didn’t have this issue in the past, perhaps try some other USB-port(s). Check with lsusb -t, ideally the soundcard is the only device on the given USB-bus. It might also be related to some CPU or bus-saving mechanism…

#5

256 [samples/cycle] / 44100 [samples/second] makes 5.8ms per process cycle.

Additional periods of buffering in the driver is not included. With jack2’s default async mode there is also another cycle added to the total round-trip latency. Ardour is not directly aware of that.

#6

Thank you very much, @x42. I’ll be definitely checking my USB ports and WiFi too (I’d never guess that one).

#7

Hi @x42,

Following your advice, I decided to turn off WiFi and started Ardour, with the same project that was having the XRun issue. This time, just one XRun showed up and for the rest of the time everything else seemed OK.

I ran the command you gave and noticed that it looks like my interface is in the same Bus as the WiFi. I don’t know very much about ports but here are the screenshot.

screenshot_18
screenshot_18.png843×395 92.2 KB

Do you think that’s the issue? Maybe I should try to keep the soundcard on its own port?

#8

Given that lsusb -t output, I’m amazed that it works at all :slight_smile:

You’re mixing all kind of USB devices with USB devices on the same Bus, also devices with different speeds (1.5 Mbit low-speed, 12 Mbit full-speed USB1.1, and some high-speed USB2 devices that can do 480MBit).

Can you try to plug the USB cable in a different port on the machine? Perhaps move the USB 1.1 devices to “bus 02” if that has some corresponding plugs on the machine.

Another thing to try: use a USB-2.0 Hub and connect all the low and full-speed devices to that hub, that can do speed transaction translation. lsusb would then only show 480M USB-2 devices. I’m not sure if that makes a significant difference, but it’s worth a try.

Still, all devices on the same usb bus (here Bus 03) share an IRQ and have equal priority. If there’s a WIFI scan going on, that may well interrupt audio. Could also be usb-storage in your case…

#9

Hi @x42,

The source of the problem was definitely WiFi. I had no idea that it was sharing the same Bus as the audio interface. And no idea about the damage that it might cause as well. But stopping it solved the problem and Ardour came back to its normality.

To be honest, I’m not familiar with the concept of Buses in the context of USB ports, and didn’t knew that WiFi had anything to do with that either. But I got the idea that is bad when you have many and different devices sharing the same Bus.

I’ll try different ports as you said. I should say that I keep all my tracks in an external HD and never create any project in the internal disk. I read somewhere in the manual that this was recommended and sticked with that since. You think that’s OK?

Thanks.

#10

usb buses are not dedicated ports because devices have to wait in turn to talk on the bus… Here I use a usb device but it is not a very demanding usb device doing only simple midi input…but I still followed jackaudio’s documentation suggestion to use a period of no less than 3 when usb is being used, so maybe you’d like to follow this suggestion…

2 Likes
#11

This is why the USB setup of any computer used for audio should be investigated. You do want the port the audio device is using to be dedicated. Look first for a USB port that does not share it’s irq with any other device (USB or not). normally at least one USB port shares irq 16 with other things. Then look for a USB port that does not have an internal hub that services internal devices. Often there will be two external USB ports that share an internal usb hub but other than that has a free irq. This means it is a good USB port to use for audio… then put tape over the other external USB plug that shares that internal hub. Find the other hub(s) that share lots of stuff and plug an external hub into that plug for mouse, keyboard, external hard drive, wifi, etc. Then go into your rtirq config file and set the priority of the USB port the Audio device is plugged into higher than the rest of the USB ports. rtirq by default is set with the USB ports lumped together and so it is possible to have a mouse with higher priority than the audio device. The priority line is normally something like: “audio usb whatever”. It should be changed to “usb3 audio usb” if the audio device is on usb3 (dmesg shows this right after the audio device is plugged in) to fix that. That is how I did things with my laptop and even running the OS on the external USB drive hooked to my “everything else” hub, I was able to record xrun free for 24hours in testing. For a desktop computer with extra PCIe slots, the very best thing is to install a USB card in a slot that does not share irq with anything else and dedicate that usb to audio. 32/2 or 32/3 should be possible if done right (assuming at least a lowlatency kernel) and 64/2 should be stable as needed while giving low enough latency for stage use as guitar effects or synth.
PCs are not designed for lowlatency audio and so it takes some work to get around the design limitations.

4 Likes
#12

pierre is having issues, not me. but thanks for the info :slight_smile:

#13

Wow. Is there a guide on how to do all this? Like how do we determine which USB ports are sharing irq? Is this a matter of opening the box and looking around or are there terminal line commands that will tell us?

#14

lsusb -t and egrep hc[di] /proc/interrupts

Some systems allow to re-assign hardware IRQ lines in the BIOS.

The bus analogy is rather fitting here. Say a bus circle route stops at 3 terminals in turn: Soundcard, CPU, and WIFI. Now if some data takes a long time to disembark at the WIFI port, the CPU<>Soundcard data-transfer will be late. So ideally the soundcard [data] is alone on a given bus.
Next you want to prioritize that bus over others – that’s where IRQs come into play.

1 Like
#15

cat /proc/interrupts
will show the interrupts, You will have to scroll up to the top for the ones you want:
23: 0 0 0 35 IO-APIC 23-fasteoi ehci_hcd:usb2
tells us that usb2 uses irq 23 and nothing else
In fact, I am seeing that none of my interrupts are shared, I guess thanks to the way pcie bus interrupts are handled. They are all virtual. So now finding out finding out if there is more than one device plugged into any one USB ports.
The first thing I found was lsusb but in my case, my cheap C-Media Electronics Inc. USB PnP Sound Device did not show up on that list. Though the list did show me I have 4 USB buses.

So I used: usb-devices which gave me tons of output. Scrolling up I noticed that each bus has at least a Host Controller. So you want a bus that only has two devices, your audio device and the host controller. I was happy to find out that each of my four USB plugs on my laptop are separate USB buses. I was less pleased to find at least four of the plugs on my desktop are all on one :stuck_out_tongue:
There are some more on the back where I can’t reach and another place on the MB I could plug the front panel to, so maybe all is not lost. In my case I use a PCI audio card so It doesn’t matter. The USB device I have is a $.60 (yes less than $1) usb audio device I use for testing… I have not yet plugged phones or mic into it to see how it sounds :slight_smile:
Anyway, the other way to see what the last plugged in device is would be to run: dmesg |tail
This handy to see what USB port each plug is, plug device in each one at a time and run dmesg then the next.
Please note, my laptop is quite old (32 bit dual core pentium? or something) though it does have the same kernel as my desktop. My desktop is an i5 about two years old or so (maybe more… it is hard to keep track) and when I always use the same plug on the front it reacts quickly but if I switch to the other port on the front there is a long delay so maybe there is some dynamic port swapping or something. I may have to use a USB3.0 port to get separation. Or use a PCIe USB card.
Nothing stays the same long enough to get to know it well …

2 Likes
#16

Hi @ahm

Could you point out where you found that information? I’m looking in JACK’s website but didn’t find anything.

#17

This is not JACK related. It’s a USB peculiarity and applies to linux’s snd_usb_audio ALSA driver.
Follow the link in the first reply above: https://www.linuxmusicians.com/viewtopic.php?f=47&t=10707

1 Like
#18

it’s actually in the manpage of jackd, "For USB audio devices it is recommended to use -n 3. "
but there’s also a lot of noise on shared usb hubs, so you’ll need to fine tune that as well…

2 Likes