This didn’t change anything.
I already noticed that. It’s strange - from what I know it’s supposed to be USB2, but then I never paid attention to it because there simply was no need to until now.
In similar scenarios, people mentioned a buggy USB3-device in other Asus systems. I have no option to manually set USB to 2 in the BIOS, and I admit I’m UEFI ignorant. At least I’m getting no option in the hardware settings menu.
Maybe you have a bad USB cable that’s only able to negotiate USB1 speed?
I’m pretty sure the main culprit here is the USB1 speed, so there’s either something strange going on with your laptop or you have a bad cable or the Edirol has gone bad.
1 Like
That is common for 2 channel audio devices. USB 2 protocol supports all USB speeds, so typically when a device is listed as USB2 it means that the device supports USB 2.0 Audio Class specification, but runs at whatever speed is required for the number of channels. 12Mb/s is more than fast enough for 2 channels, so typically only the multi-channel interfaces run at 480Mb/s.
OK, I thought it might be worth a try. Just to make sure, you did restart the rtirq service after making the change, and check with rtirq status to make sure it actually modified the RT priority of the interrupt handlers?
In the specs I cannot see a reference to a USB version at all:
I would expect it’s USB 2 but it isn’t specifically stated. The Roland Zendesk, however, suggests this:
Be sure that you are connecting to a USB 2.0 port on your computer; or a USB 3.0 port with backwards compatibility. Check the USB 3.0 specifications of your computer to determine if there is complete support for USB backwards compatibility.
https://rolandus.zendesk.com/hc/en-us/articles/115002808766-UA-4FX-Troubleshooting-USB-Connection-Noise-Dropout-and-Latency-Issues
Changed to another cable that definitely connects devices with USB 2, but I’m still getting
|__ Port 11: Dev 10, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 10, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 10, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12
I have changed the line to a sole entry
RTIRQ_NAME_LIST=“usb11”
and restarted the service. Maybe the option is altogether wrong? Here’s the output:
$ sudo /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
124 FF 50 - 90 0.0 S irq/9-acpi
132 FF 50 - 90 0.0 S irq/122-PCIe BW
134 FF 50 - 90 0.0 S irq/123-PCIe BW
136 FF 50 - 90 0.0 S irq/124-PCIe BW
141 FF 50 - 90 0.0 S irq/125-mei_me
184 FF 50 - 90 0.0 S irq/126-nvme0q0
185 FF 50 - 90 0.0 S irq/127-nvme0q1
186 FF 50 - 90 0.0 S irq/128-nvme0q2
187 FF 50 - 90 0.0 S irq/129-nvme0q3
188 FF 50 - 90 0.0 S irq/130-nvme0q4
250 FF 50 - 90 0.0 S irq/8-rtc0
253 FF 50 - 90 0.0 S irq/16-i801_smb
255 FF 50 - 90 0.2 S irq/132-xhci_hc
257 FF 50 - 90 0.3 S irq/133-ahci[00
272 FF 50 - 90 0.0 S irq/134-i915
562 FF 50 - 90 0.0 S irq/135-iwlwifi
133 FF 49 - 89 0.0 S irq/122-s-PCIe
135 FF 49 - 89 0.0 S irq/123-s-PCIe
137 FF 49 - 89 0.0 S irq/124-s-PCIe
563 FF 49 - 89 0.0 S irq/135-s-iwlwi
9 TS - 0 38 0.2 S ksoftirqd/0
18 TS - 0 38 0.0 S ksoftirqd/1
24 TS - 0 38 0.1 S ksoftirqd/2
30 TS - 0 38 0.2 S ksoftirqd/3
547 ISO 0 - 39 0.0 S irq/131-enp1s
(forget the network related stuff, this is after a reboot. I normally disable the network interfaces on boot or unload the modules respectively)
while my original setting
RTIRQ_NAME_LIST=“snd usb i8042”
gives me
$ sudo /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
255 FF 85 - 125 0.1 S irq/132-xhci_hc
124 FF 50 - 90 0.0 S irq/9-acpi
132 FF 50 - 90 0.0 S irq/122-PCIe BW
134 FF 50 - 90 0.0 S irq/123-PCIe BW
136 FF 50 - 90 0.0 S irq/124-PCIe BW
141 FF 50 - 90 0.0 S irq/125-mei_me
184 FF 50 - 90 0.0 S irq/126-nvme0q0
185 FF 50 - 90 0.0 S irq/127-nvme0q1
186 FF 50 - 90 0.0 S irq/128-nvme0q2
187 FF 50 - 90 0.0 S irq/129-nvme0q3
188 FF 50 - 90 0.0 S irq/130-nvme0q4
250 FF 50 - 90 0.0 S irq/8-rtc0
253 FF 50 - 90 0.0 S irq/16-i801_smb
257 FF 50 - 90 0.0 S irq/133-ahci[00
272 FF 50 - 90 0.0 S irq/134-i915
562 FF 50 - 90 0.0 S irq/135-iwlwifi
133 FF 49 - 89 0.0 S irq/122-s-PCIe
135 FF 49 - 89 0.0 S irq/123-s-PCIe
137 FF 49 - 89 0.0 S irq/124-s-PCIe
563 FF 49 - 89 0.0 S irq/135-s-iwlwi
9 TS - 0 38 0.0 S ksoftirqd/0
18 TS - 0 38 0.0 S ksoftirqd/1
24 TS - 0 38 0.0 S ksoftirqd/2
30 TS - 0 38 0.0 S ksoftirqd/3
547 ISO 0 - 39 0.0 S irq/131-enp1s0
I don’t think you have usb11.
If you do a cat /proc/interrupts you’ll probably only have usb1 and 2; corresponding to Bus 02 and 01.
I have 5 busses on my PC and usb1-5 in /proc/interrupts.
I also found that in order to get down to 64 frames/period without xruns on my Komplete Audio 6 I had to disable all but one CPU core.
FYI:
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 10 0 0 0 IR-IO-APIC 2-edge timer
8: 0 1 0 0 IR-IO-APIC 8-edge rtc0
9: 0 5 0 0 IR-IO-APIC 9-fasteoi acpi
16: 0 0 0 0 IR-IO-APIC 16-fasteoi i801_smbus
120: 0 0 0 0 DMAR-MSI 0-edge dmar0
121: 0 0 0 0 DMAR-MSI 1-edge dmar1
122: 0 0 0 0 IR-PCI-MSI 458752-edge PCIe BW notif
123: 0 0 0 0 IR-PCI-MSI 471040-edge PCIe BW notif
124: 0 0 0 0 IR-PCI-MSI 475136-edge PCIe BW notif
125: 0 0 46 0 IR-PCI-MSI 360448-edge mei_me
126: 0 0 0 23 IR-PCI-MSI 1572864-edge nvme0q0
127: 19 0 0 0 IR-PCI-MSI 1572865-edge nvme0q1
128: 0 35 0 0 IR-PCI-MSI 1572866-edge nvme0q2
129: 0 0 65 0 IR-PCI-MSI 1572867-edge nvme0q3
130: 0 0 0 67 IR-PCI-MSI 1572868-edge nvme0q4
131: 0 0 51 24426 IR-PCI-MSI 524288-edge enp1s0
132: 0 0 167826 1634 IR-PCI-MSI 327680-edge xhci_hcd
133: 10471 12985 0 0 IR-PCI-MSI 376832-edge ahci[0000:00:17.0]
134: 21262 797 5737 0 IR-PCI-MSI 32768-edge i915
135: 0 0 0 27 IR-PCI-MSI 1048576-edge iwlwifi
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 94457 250899 718903 848969 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
IWI: 3932 12 1413 2 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 88430 273036 636094 807046 Rescheduling interrupts
CAL: 14535 20533 26076 27489 Function call interrupts
TLB: 29123 40595 55253 62881 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
DFR: 0 0 0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 40 41 41 41 Machine check polls
HYP: 0 0 0 0 Hypervisor callback interrupts
HRE: 0 0 0 0 Hyper-V reenlightenment interrupts
HVS: 0 0 0 0 Hyper-V stimer0 interrupts
ERR: 0
MIS: 0
PIN: 0 0 0 0 Posted-interrupt notification event
NPI: 0 0 0 0 Nested posted-interrupt event
PIW: 0 0 0 0 Posted-interrupt wakeup event
OK, maybe the xhci driver reports differently than the uhci and ehci ones.
I’ve got
cat /proc/interrupts | grep usb
16: 2880 0 0 4275 IO-APIC 16-fasteoi ehci_hcd:usb1
20: 0 0 0 0 IO-APIC 20-fasteoi uhci_hcd:usb4
21: 0 0 0 0 IO-APIC 21-fasteoi uhci_hcd:usb5
22: 015058 0 0 IO-APIC 22-fasteoi ehci_hcd:usb3
23: 6364 2506 0 0 IO-APIC 23-fasteoi ehci_hcd:usb2
with my sound card on the usb3 port, so I have
RTIRQ_NAME_LIST=“usb3"
I don’t know exactly how you’d do it but maybe you can blacklist the xhci driver and force it to use ehci and uhci instead, and see if that works better.
Just be prepared with a Live USB, in case you lose the keyboard and mouse functionality when changing the drivers.
I’ve done this now:
modprobe -r xhci_pci xhci_hcd
This removes the xhci modules (checked).
dmesg:
…
xhci_hcd 0000:00:14.0: remove, state 1
usb usb2: USB disconnect, device number 1
usb 2-4: USB disconnect, device number 2
usb 2-4.2: USB disconnect, device number 3
xhci_hcd 0000:00:14.0: USB bus 2 deregistered
xhci_hcd 0000:00:14.0: remove, state 1
usb usb1: USB disconnect, device number 1
usb 1-1: USB disconnect, device number 2
usb 1-4: USB disconnect, device number 3
usb 1-7: USB disconnect, device number 4
hid-generic 0003:0461:4E99.0002: can’t resubmit intr, 0000:00:14.0-9.4/input0, status -19
[usb 1-8: USB disconnect, device number 5
usb 1-9: USB disconnect, device number 6
usb 1-9.4: USB disconnect, device number 8
usb 1-14: USB disconnect, device number 7
xhci_hcd 0000:00:14.0: USB bus 1 deregistered
The USB bus and all USB devices are gone. lsusb returns no result.
modprobe ehci_pci ehci_hcd
This loads the modules, I can see them with
lsmod|grep ehci
ehci_pci 16384 0
ehci_hcd 73728 1 ehci_pci
dmesg:
…
ehci_hcd: USB 2.0 ‘Enhanced’ Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
…
Anyway, the USB bus doesn’t show up, and no devices connect.
After unloading ehci_* and reloading xhci_*, I’m back to normal.
The Hardware has to have the ehci firmware available too. Many newer MB do not. Many of these route all USB1/2 devices to one bus. The only way around this I have seen is to install a PCIe USB card just for audio. In your case I see only one xhci module anyway, so only one bus for all USB stuff? Not good. As you have a desktop… add a PCIe USB card. A USB 2.0 card would be fine (and maybe easier to deal with) but a USB3 card would be fine too. Then, after install, check that it is not sharing an IRQ with anything else. If it is try another PCIe slot if you can. Use this new USB card only for Audio, leave mouse, kb, printer, whatever, connected to the MB. You should be able to figure out the module running your new card because audio devices put most of their interrupts on one core… easy to see. Then use ps xa to find that irq, it will look something like: irq/20-xhci_hcd or irq/20-ehci_hcd. While there is no sure way to know that the system will assign the same irq every time, it generally does unless you add more hw. use the irq-xhci (like 20-xhci) part in the rtirq line as the first entry rather than usb. That way you don’t end up with your mouse having a higher priority than the sound card (Which using usb can do)
Do check that rtirq is doing the job (/etc/init.d/rtirq status). I have seen it run before the item I am trying to fix is visible to the system… you can disable the startup script and add it to /etc/rc.local with a sleep 30 first so that the system has had 30 seconds to start up first. Or run it by hand after startup (sudo /etc/init.d/rtirq restart).
Dealing with /etc/init.d/ seems to vary from system to system… with system.d making things even more fun so I won’t even try to tell you how…
I have added a PCIe USB3 card from a cannibalised workstation now.
$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 2, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 2, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
/: 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 7: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 11: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 14: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 14: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
Bus 03 and 04 are the ports from the added card. The audio device is the only device attached to it.
$ sudo lspci -v
…
01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at df300000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
Capabilities: [150] Latency Tolerance Reporting
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
Apparently no interrupts have multiple use:
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 7 0 0 0 IR-IO-APIC 2-edge timer
8: 0 0 1 0 IR-IO-APIC 8-edge rtc0
9: 0 4 0 0 IR-IO-APIC 9-fasteoi acpi
16: 0 0 0 0 IR-IO-APIC 16-fasteoi i801_smbus
120: 0 0 0 0 DMAR-MSI 0-edge dmar0
121: 0 0 0 0 DMAR-MSI 1-edge dmar1
122: 0 0 0 13 IR-PCI-MSI 2097152-edge nvme0q0
123: 6557 6588 0 6113 IR-PCI-MSI 376832-edge ahci[0000:00:17.0]
124: 0 36943 414 0 IR-PCI-MSI 327680-edge xhci_hcd
125: 0 27339 0 33 IR-PCI-MSI 524288-edge xhci_hcd
126: 0 0 0 0 IR-PCI-MSI 524289-edge xhci_hcd
127: 0 0 0 0 IR-PCI-MSI 524290-edge xhci_hcd
128: 0 0 0 0 IR-PCI-MSI 524291-edge xhci_hcd
129: 0 0 0 0 IR-PCI-MSI 524292-edge xhci_hcd
130: 43 0 0 5494 IR-PCI-MSI 1048576-edge enp2s0
131: 0 686 18380 0 IR-PCI-MSI 32768-edge i915
132: 73 0 0 0 IR-PCI-MSI 2097153-edge nvme0q1
133: 0 58 0 0 IR-PCI-MSI 2097154-edge nvme0q2
134: 0 0 28 0 IR-PCI-MSI 2097155-edge nvme0q3
135: 0 0 0 52 IR-PCI-MSI 2097156-edge nvme0q4
136: 0 0 39 0 IR-PCI-MSI 360448-edge mei_me
137: 0 0 0 39 IR-PCI-MSI 1572864-edge iwlwifi
NMI: 4 4 4 4 Non-maskable interrupts
LOC: 185509 184471 176821 177618 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 4 4 4 4 Performance monitoring interrupts
IWI: 303 230 108 82 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 40882 29931 20855 16248 Rescheduling interrupts
CAL: 16562 15999 15418 18290 Function call interrupts
TLB: 12692 12458 12424 16042 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
DFR: 0 0 0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 5 6 6 6 Machine check polls
HYP: 0 0 0 0 Hypervisor callback interrupts
HRE: 0 0 0 0 Hyper-V reenlightenment interrupts
HVS: 0 0 0 0 Hyper-V stimer0 interrupts
ERR: 0
MIS: 0
PIN: 0 0 0 0 Posted-interrupt notification event
NPI: 0 0 0 0 Nested posted-interrupt event
PIW: 0 0 0 0 Posted-interrupt wakeup event
/etc/default/rtirq:
RTIRQ_NAME_LIST=“snd usb i8042”
Still no change - xruns when flipping windows.
In theory my mouse could have priority over the audio device - how can I tell?
/etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
82 FF 90 - 130 0.0 S irq/8-rtc0
167 FF 85 - 125 0.1 S irq/124-xhci_hc
168 FF 84 - 124 0.8 S irq/125-xhci_hc
169 FF 83 - 123 0.0 S irq/126-xhci_hc
170 FF 82 - 122 0.0 S irq/127-xhci_hc
171 FF 81 - 121 0.0 S irq/128-xhci_hc
172 FF 80 - 120 0.0 S irq/129-xhci_hc
59 FF 50 - 90 0.0 S irq/9-acpi
159 FF 50 - 90 0.0 S irq/16-i801_smb
175 FF 50 - 90 0.0 S irq/131-i915
176 FF 50 - 90 0.0 S irq/123-ahci[00
196 FF 50 - 90 0.0 S irq/122-nvme0q0
197 FF 50 - 90 0.0 S irq/132-nvme0q1
198 FF 50 - 90 0.0 S irq/133-nvme0q2
199 FF 50 - 90 0.0 S irq/134-nvme0q3
200 FF 50 - 90 0.0 S irq/135-nvme0q4
391 FF 50 - 90 0.0 S irq/136-mei_me
…
It appears one of these two is the one serving your audio device. Perhaps you tried both? Note the high number of interrupts on one core. So you want either irq 124 or 125.
All of your usb devices are here in order with 124 being the highest. That would suggest, as you are still having trouble, that 124 is not the one you want. (not sure yet).
lets change that:
RTIRQ_NAME_LIST=“125-xhci snd i8042 usb”
You will of course need a reboot for each change. You can try replacing the 125 with any of the other 124 - 129 but as only 124 and 125 actually have interrupts showing from cat /proc/interrupts I would expect one of those two is your sound card.
It shows 4 threads, is that 4 cores or two cores with hyperthread? When I still had a machine with hyperthreading, I had to turn it off for latencies less than about 128 to have no xruns. The only other big irq user looks like your i915 (graphics I would guess) but that shouldn’t be a problem in my experience… not that my experience is great and wide, I have only used 3 or 4 cpus/gpus so not a lot.
You can restart rtirq, it will re-order the priorities dynamically without rebooting.
Last time I tried this, anything that already had raised priority was not moved (lowered) to make room for a new high priority item. Maybe this has changed and in my case I had to do that for something that was not “ready” when rtirq ran at boot and so reran it. The outcome was not as expected.
It’s four physical cores. i915 is the graphics adapter.
That explains why trying to explicitly move the USB Port you want higher does not work. Compare that xhci listing in /proc/interrupts with one from a USB2 controller posted by Peter Hedlund:
The EHCI and UHCI entries include the port number in the IRQ listing. I do not know why the XHCI driver does not do that.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.