I have booted the Debian RT kernel with the “threadirqs” option but sadly it doesn’t seem to make any difference. I have yet to try connecting the audio device to another USB bus (probably need a new cable for it) but in fact I don’t expect much here. Only keyboard and mouse are on the same bus which I believe used to be the case on the old system. Anyway, thanks a lot so far, I was totally unaware of the “threadirqs” option.
I thought the threadirqs option is only needed for low latency kernels, but not for RT kernels.
Does this also affect the Debian non RT kernel?
Did you try a different window manager (e.g. openbox) for testing? Do you use compositing and does it change when you turn it off?
Have you also installed rtirq-init?
The reason to use threadirqs is to allow rtirq to prioritize IRQs (prefer the soundcard, or here USB, over other hardware, e.g. graphics).
You can force-enable it when configuring the kernel. Some PREEMP-RT patched kernels include this option.
1 Like
What is the DSP load when idling with a session open ? In this thread a high DSP load on idle was solved by moving the sound card to usb-c.
An idle session has a DSP load of 9-11%. With guitarix started, it goes up to 16% and with Ardour and a loaded project it normally stays just under 20%. Xruns even occur (rarely, though) with both guitarix and Ardour with a loaded project open, but transport not running (i. e. playing back).
Yes, installed per the standard Debian sources. The version no. is 20150216-2 which appears to be quite old.
I’ve tried other, more frugal window managers like jvm, to no avail. I’ve always used xfwm4, with compositing eyecandy deactivated. I’ll give openbox a try since you mentioned it but I don’t expect a radical change here.
Coming back to the rtirq topic - /etc/init.d/rtitq status gives me
167 FF 85 - 125 2.2 S irq/124-xhci_hc
59 FF 50 - 90 0.0 S irq/9-acpi
82 FF 50 - 90 0.0 S irq/8-rtc0
159 FF 50 - 90 0.0 S irq/16-i801_smb
170 FF 50 - 90 0.0 S irq/126-i915
171 FF 50 - 90 0.0 S irq/123-ahci[00
[…]
which means the USB driver already has a priority over the graphics card. Is that correct?
Yes it is.
It may still be possible that the graphics-card can hog the bus for along time. but with i915 driver that should not be the case.
What does lsusb -t show? Are there other USB devices that could interfere?
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 11: Dev 6, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 6, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 6, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 14: Dev 7, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 14: Dev 7, If 1, Class=Wireless, Driver=btusb, 12M
Notes: I only use keyboard and mouse, no other USB devices (apart from the audio device of course). I cannot deactivate Bluetooth in the BIOS, but unloading the BT modules makes no difference that I notice. One option would be to move the audio device to Bus02 but I need to get a proper USB-C adapter first. I still doubt there would be a radical change.
My old system had an i945 graphics card running on an i915 driver, and like I said, it performed very well and threw xruns only under high loads.
Now I’m confused. Bought a USB3 hub with USB-C and attached it to the USB-C socket on the front panel.
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
[…]
Good, that’s what you’d expect. Now I plugged the USB audio device into the hub - and:
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 8: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 16, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 16, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 16, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 14: Dev 7, If 0, Class=Wireless, Driver=, 12M
|__ Port 14: Dev 7, If 1, Class=Wireless, Driver=, 12M
Why does it still show up on Bus 1?
Mouse actions on the desktop seem to be the source of xruns. Namely when moving Ardour windows (I typically have both the editor and mixer window open), xruns appear in hundreds, and the DSP load display on the top right side of the editor window goes up to above 90% and turns red, even when nothing is being played back. Moving the window with playback on heavily distorts the sound.
Since it appears you are using Jack… can you post up the message log when you start Jack? I am curious if it is actually starting in real time mode (I don’t see a -R in your command, and I can’t remember if it runs in real time without that or not)
SeabladeSun May 31 02:38:10 2020: Starting jack server…
Sun May 31 02:38:10 2020: JACK server starting in realtime mode with priority 10
Sun May 31 02:38:10 2020: self-connect-mode is “Don’t restrict self connect requests”
Sun May 31 02:38:10 2020: Acquired audio card Audio1
Sun May 31 02:38:10 2020: creating alsa driver … hw:UA4FX|hw:UA4FX|64|3|48000|0|0|nomon|swmeter|-|32bit
Sun May 31 02:38:10 2020: configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 3 periods
Sun May 31 02:38:10 2020: ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format
Sun May 31 02:38:10 2020: ALSA: use 3 periods for capture
Sun May 31 02:38:10 2020: ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
Sun May 31 02:38:10 2020: ALSA: use 3 periods for playback
I think I remember jackd is running in RT mode by default.
Did you test what happens when period=256 frames?
It makes no difference.
It appears that bus 2 is only used for USB3, and all USB2 devices get connected to bus 1. When you connect the USB audio it is using the USB2 portion of the hub, not the USB3 portion of the hub. You can see that bus 2 has the “5000M” indicating 5Gb/s operation, but on bus 1 there is also a new hub device on port 8 running at 480Mb/s, USB2 high speed.
That unfortunately probably means that your computer only has one USB2 controller and one USB3 controller, so there does not seem to be any way to get your mouse and keyboard on a different controller than the audio interface (unless there are other USB ports you did not mention).
You may be able to configure rtirq to improve performance. Try putting USB11 as the only entry in your rtirq config file RTIRQ_NAME_LIST entry and restart rtirq. That may be able to prioritize the audio driver over the mouse driver. I am not sure how well that works when all the devices are controlled by a single USB controller though, you will just have to test it and see.
One option is to disable xhci in EFI. This will disable USB3 and set all your ports to USB2 mode.
I need to do this for one of my laptops (Asus ROG G75VW), since it’s usb3 feature is somehow broken and I’m getting crackling in my audio. Everything works flawlessly when I disable xhci and usb3.