Hi there,
I’m using ardour on AVLinux, cat /etc/*version
output:
AV_Linux_MX_Edition-21.3_ahs_x64 Consciousness January 25, 2023
11.7
AV_Linux_MX_Edition-21.3_ahs_x64 Consciousness January 25, 2023
I’m using Liquorix kernel, which should have some realtime-kernel feature (preempt), sudo uname -a output:
Linux elaudio 6.0.0-10.1-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.0-6~mx21+1 (2022-11-30) x86_64 GNU/Linux
My USB Audio Interface is M-AUDIO MTrack II Plus.
I’m running Jack with following settings:
Sample Rate: 44100
Frames/Period: 128
Periods/Buffer: 3
I’m having issues trying to play/record in Ardour using the free VSTs used in this guide. I tried to record a track with this setup and I noticed QjackCtl showed a lot of xruns (something in the order or 20 or more…), furthermore after some time recording/playing/having Ardour opened (with connections made) with a Track which includes these VSTs, the O.S. systematically freezes completely, stopping me from doing anything and forcing me to reboot using the power button, which I find really weird… Is there a simple explanation to this freeze?
Looking at the message tab of QjackCtl I can see the xruns come in the form of:
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
01:00:02.906 XRUN callback (1).
or
JackEngine::XRun: client = ardour was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
01:00:03.739 XRUN callback (1 omitidos).
with the numbers inside the round brackets being incremental.
My PC specs should be ok since I’m working with 32Gb of RAM and an Intel i7 13th Gen CPU.
I think my issue could be similar to the problem described in this topic, where the user was having xruns due to other device/s accessing and holding the bus for a long time, avoiding the USB interface to deliver/receive audio. I tried to follow the topic, but unfortunately I wasn’t able to implement your advices… I issued the lsusb -t command to get some information about my USB devices and buses, here’s the output:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 20000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 3, Class=Application Specific Interface, Driver=, 480M
|__ Port 1: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 1: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 1: Dev 2, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 8: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 9: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 9: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 10: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 10: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
As you can see, all my USB devices unfortunately share the same bus… You can also see I’m using two audio interfaces: one is the M-AUDIO M-Track (Dev 2) and the other is a MIO iConnectivity MIDI to USB interface (Dev 4) I use to drive plugins playing soundfonts and instruments.
I also already tried to connect my USB M-AUDIO interface to all my USB ports and it always appears connected on the same bus (Bus 01).
I also issued egrep hc[di] /proc/interrupts to try to spot USB devices which are sharing IRQs and I got the following output:
124: 0 0 0 0 0 0 0 0 0 0 12349172 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 327680-edge xhci_hcd
127: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 376832-edge ahci[0000:00:17.0]
But I really don’t know how to interpret and cross-reference the data…
I understood devices use IRQs to issue an interrupt and requesting immediate action from the CPU to their data, also if multiple devices share the same bus, one device has to wait the other one has finished with the bus before the CPU can handle its request, I also understood you can assign priorities to IRQ numbers, but if multiple devices share the same IRQ number and you try to prioritize that IRQ number (to make the audio interface take priority over all other devices on the same bus), this will affect all the devices sharing that IRQ number and not only the audio interface…
Yet still I can’t use this information to get the job done… More specifically:
- How am I supposed to cross-reference the data from egrep hc[di] /proc/interrupts command to get the USB devices sharing the same IRQ number? Looking at the output of the command it seems that IRQ 124 is used by xhci_hcd device and IRQ 127 is used by ahci[0000:00:17.0] one, but which devices are these? Are they my audio interfaces? I also see that the two devices use different IRQ numbers, does that mean I can solve the problem prioritizing one IRQ number over all the others?
- How can I prioritize an IRQ number over the others? Should I change some configuration in the bios or is there some configuration I can do at O.S. level?
I also tried to download and use a realtime kernel (5.10.0-23-rt-amd64) but I still got xruns; maybe a little bit less, but still in the order of one per 3/10 seconds, I’ve not experienced no O.S. freezing though.
I also don’t have WiFi interface since I’m connected via ethernet, so we can’t assume the problem is the WiFi interface searching for networks and meanwhile holding the bus…
Maybe @x42 or @lenovens could give me an hand with this issue?
Thanks in advance for the help