RTIRQ - Did I do this correctly?

[Glennbo]

I started thinking about rtirq and remembered setting it for my M-Audio cards. Well sure enough rtirq status reported that the M-Audio card still had a priority of 95, which I no longer need. There is only one M-Audio card in my machine now and it's set to be computer audio. The Intel audio is disabled in the bios.

I *think* IRQ 23 is the guy with my new USB sound device. Does this look correct?

I've had a few instances where sound gapped on me like to the tune of a quarter of a second pause, almost always while I had other stuff running like I have always done with the M-Audio cards. It did it once with nothing else running when I moved my mouse real fast across the screen and that's what made me remember rtirq.


So after searching the net I found one thread where a guy changed

RTIRQ_NAME_LIST="snd"

to

RTIRQ_NAME_LIST="ehci_hcd"

I tried it and here's what /proc/asound/cards comes back with now.

0 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xfbcfc000 irq 17
1 [UMC1820 ]: USB-Audio - UMC1820
BEHRINGER UMC1820 at usb-0000:00:1d.0-1.1, high speed
2 [M2496 ]: ICE1712 - M Audio Audiophile 24/96
M Audio Audiophile 24/96 at 0xec00, irq 16


In particular the output from sudo /etc/init.d/rtirq status


PID CLS RTPRIO NI PRI %CPU STAT COMMAND
103 FF 95 - 135 0.0 S irq/16-ehci_hcd
104 FF 94 - 134 0.1 S irq/23-ehci_hcd
48 FF 50 - 90 0.0 S irq/9-acpi
106 FF 50 - 90 0.0 S irq/12-i8042
107 FF 50 - 90 0.0 S irq/1-i8042
108 FF 50 - 90 0.0 S irq/8-rtc0
179 FF 50 - 90 0.0 S irq/19-pata_jmi
186 FF 50 - 90 0.8 S irq/29-ahci[000
205 FF 50 - 90 0.0 S irq/18-ahci[000
524 FF 50 - 90 0.0 S irq/17-snd_hda_
528 FF 50 - 90 0.0 S irq/16-snd_ice1
939 FF 50 - 90 0.0 S irq/30-enp2s0
949 FF 50 - 90 0.0 S irq/31-nvidia
950 FF 49 - 89 0.0 S irq/31-s-nvidia
7 TS - 0 19 0.2 S ksoftirqd/0
17 TS - 0 19 0.2 S ksoftirqd/1
23 TS - 0 19 0.1 S ksoftirqd/2
29 TS - 0 19 0.2 S ksoftirqd/3


Here's the output from sudo cat /proc/interrupts


CPU0 CPU1 CPU2 CPU3
0: 112 0 0 0 IO-APIC 2-edge timer
1: 0 2 0 0 IO-APIC 1-edge i8042
8: 0 0 1 0 IO-APIC 8-edge rtc0
9: 0 121 0 0 IO-APIC 9-fasteoi acpi
12: 4 0 0 0 IO-APIC 12-edge i8042
16: 0 0 98 0 IO-APIC 16-fasteoi ehci_hcd:usb1, snd_ice1712
17: 0 0 715 0 IO-APIC 17-fasteoi snd_hda_intel:card0
18: 0 0 0 0 IO-APIC 18-fasteoi ahci[0000:03:00.0]
19: 0 0 134 138 IO-APIC 19-fasteoi pata_jmicron
23: 0 0 0 4446 IO-APIC 23-fasteoi ehci_hcd:usb2
24: 18204 0 0 0 HPET-MSI 2-edge hpet2
25: 0 16185 0 0 HPET-MSI 3-edge hpet3
26: 0 0 15964 0 HPET-MSI 4-edge hpet4
27: 0 0 0 21706 HPET-MSI 5-edge hpet5
29: 14570 0 0 0 PCI-MSI 512000-edge ahci[0000:00:1f.2]
30: 53 0 0 1240 PCI-MSI 1048576-edge enp2s0
31: 0 281 0 54 PCI-MSI 524288-edge nvidia
NMI: 11 10 10 14 Non-maskable interrupts
LOC: 86 71 63 55 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 11 10 10 14 Performance monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RTR: 1 0 0 0 APIC ICR read retries
RES: 5146 5632 8602 3739 Rescheduling interrupts
CAL: 7825 5729 5844 5573 Function call interrupts
TLB: 5814 3976 3800 4052 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: 1 2 2 2 Machine check polls
HYP: 0 0 0 0 Hypervisor callback interruptssudo cat /proc/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

[Glennbo]

I've got one of my most demanding projects running in REAPER along with all the normal junk I run every day and when I scroll real fast in this editor I can sometimes introduce a gap in audio playback. It doesn't happen very frequently, but enough to see a correlation.

So which of these two lines looks more like what I want for a Behringer UMC1820 on a USB2 port? Old machine, no USB3 ports.

RTIRQ_NAME_LIST="rtc ehci snd"

or

RTIRQ_NAME_LIST="ehci_hcd"



Using RTIRQ_NAME_LIST="ehci_hcd" I was getting this.

PID CLS RTPRIO NI PRI %CPU STAT COMMAND
103 FF 95 - 135 0.0 S irq/16-ehci_hcd
104 FF 94 - 134 0.1 S irq/23-ehci_hcd
48 FF 50 - 90 0.0 S irq/9-acpi
106 FF 50 - 90 0.0 S irq/12-i8042
107 FF 50 - 90 0.0 S irq/1-i8042
108 FF 50 - 90 0.0 S irq/8-rtc0
179 FF 50 - 90 0.0 S irq/19-pata_jmi
186 FF 50 - 90 0.8 S irq/29-ahci[000
205 FF 50 - 90 0.0 S irq/18-ahci[000
524 FF 50 - 90 0.0 S irq/17-snd_hda_
528 FF 50 - 90 0.0 S irq/16-snd_ice1
939 FF 50 - 90 0.0 S irq/30-enp2s0
949 FF 50 - 90 0.0 S irq/31-nvidia
950 FF 49 - 89 0.0 S irq/31-s-nvidia
7 TS - 0 19 0.2 S ksoftirqd/0
17 TS - 0 19 0.2 S ksoftirqd/1
23 TS - 0 19 0.1 S ksoftirqd/2
29 TS - 0 19 0.2 S ksoftirqd/3

Trying RTIRQ_NAME_LIST="rtc ehci snd" now I get this.

PID CLS RTPRIO NI PRI %CPU STAT COMMAND
108 FF 95 - 135 0.0 S irq/8-rtc0
103 FF 94 - 134 0.0 S irq/16-ehci_hcd
104 FF 93 - 133 0.1 S irq/23-ehci_hcd
545 FF 93 - 133 0.0 S irq/17-snd_hda_
559 FF 93 - 133 0.0 S irq/16-snd_ice1
48 FF 50 - 90 0.0 S irq/9-acpi
106 FF 50 - 90 0.0 S irq/12-i8042
107 FF 50 - 90 0.0 S irq/1-i8042
189 FF 50 - 90 0.0 S irq/19-pata_jmi
197 FF 50 - 90 1.0 S irq/29-ahci[000
216 FF 50 - 90 0.0 S irq/18-ahci[000
1008 FF 50 - 90 0.0 S irq/30-enp2s0
1020 FF 50 - 90 0.0 S irq/31-nvidia
1021 FF 49 - 89 0.0 S irq/31-s-nvidia
7 TS - 0 19 0.2 S ksoftirqd/0
17 TS - 0 19 0.2 S ksoftirqd/1
23 TS - 0 19 0.2 S ksoftirqd/2
29 TS - 0 19 0.2 S ksoftirqd/3

[lilith93]

Hi,

You might want to look at this thread:

https://linuxmusicians.com/viewtopic...=Xruns+but+why

to find you interface let the project run in Reaper and look with

cat /proc/interrupts

for the line for which the numbers are increasing most quickly. If you stop Jack the number should stop increading. It's explained in the thread.

[Glennbo]

Originally Posted by lilith93

Hi,

You might want to look at this thread:

https://linuxmusicians.com/viewtopic...=Xruns+but+why

to find you interface let the project run in Reaper and look with

cat /proc/interrupts

for the line for which the numbers are increasing most quickly. If you stop Jack the number should stop increading. It's explained in the thread.

I'm using ALSA so far, as this is a brand new interface and a fresh install of Xubuntu after a storm whacked the one I was using.

As I had mentioned, I believe the IRQ my new audio interface is using indirectly through USB is #23. cat /proc/interrupts comes back with this line in particular.

23: 0 0 0 14363892 IO-APIC 23-fasteoi ehci_hcd:usb2

And a sudo /etc/init.d/rtirq status comes back with this, showing priority of 94 on IRQ 23 if I read all this alien stuff correctly.

103 FF 95 - 135 0.0 S irq/16-ehci_hcd
104 FF 94 - 134 0.7 S irq/23-ehci_hcd

[lilith93]

You can try to set the priority lower and see if it gets worse.

[s wave]

stupid answer here but... Look at syslog (and auth.log/dpkg.log/xorg0log)
I keep them running - so I can spot abnormalities.

[Glennbo]

Thanks for the responses. I'm pretty sure I've got it set correctly after booting into Windows and looking at the device manager by connection, which agrees with what I thought was the case. The new Behringer UMC1820 is on the USB port that is serviced by IRQ #23, and rtirq status says IRQ #23 has 94% priority.

103 FF 95 - 135 0.0 S irq/16-ehci_hcd
104 FF 94 - 134 0.1 S irq/23-ehci_hcd

So unless there is some other way of upping the priority other than giving it to the host USB port that the audio device is connected to, I think I have got it now.

Are there other tweaks that should be made for a USB based sound device?

[JamesPeters]

So I recently realized what I'd done with RTIRQ wasn't doing anything. I had to run (sudo) "rtirq start". Then I checked using rtirq status and I could see the RTprio become what I specified.

Anyway after I set the audio device to 95, I was able to lower my latency to the lowest I've ever done it, just over 4ms round-trip (and confirmed, not just the reported latency) at 44.1 KHz. 6 blocks of 32 samples is the setting I can now use, and it's stable up to 100% CPU. Lol.

Another thing I realized though: setting the RT priority that high for the audio device isn't necessarily all good. When the CPU is being stressed hard, to prevent xruns it means Reaper starts acting less responsive (moving faders, for instance). That's ok, but there's a "middle ground" where you're just using the CPU "a fair bit" and maybe you want the controls to be more responsive. Setting audio device RT priority at 70 for instance seems like a nice compromise of being able to get the lowest possible latency and also good responsiveness even when the CPU is being slammed with lots of plugins (at the expense of the odd xrun). Then when I set my buffer to 4 blocks of 128, it's solid up to 100% CPU and responsive.

Note: I'm using ALSA in Reaper. In the audio device settings dialog, there's a setting to change the RT priority.

Also I played around changing Reaper's (ALSA) RT priority. It seems keeping it lower than the audio card's RT priority means fewer xruns when you're pushing things to extremes (super low latency and highest CPU use), but Reaper feels less responsive at the same time. If you increase Reaper's (ALSA) RT priority it will be more responsive but then it can have more xruns. I tried setting the audio device's RT priority to 95 and Reaper (ALSA) RT priority to 80 (then 70, etc.) but it seems the best balance was to keep Reaper (ALSA) RT priority around 40 as recommended in the settings dialog (then put the audio device's RT priority around 70).

[lilith93]

I have my soundcard set to a priority of 90 and Jack to 88. Everything below 99 or 98 should be fine. As I'm using Jack all the time Reaper is running with the priority of Jack. My sample rate is typically 528 as I don't need ultra low latency. I prefer a cooler CPU

Originally Posted by JamesPeters

So I recently realized what I'd done with RTIRQ wasn't doing anything. I had to run (sudo) "rtirq start". Then I checked using rtirq status and I could see the RTprio become what I specified.

Anyway after I set the audio device to 95, I was able to lower my latency to the lowest I've ever done it, just over 4ms round-trip (and confirmed, not just the reported latency) at 44.1 KHz. 6 blocks of 32 samples is the setting I can now use, and it's stable up to 100% CPU. Lol.

Another thing I realized though: setting the RT priority that high for the audio device isn't necessarily all good. When the CPU is being stressed hard, to prevent xruns it means Reaper starts acting less responsive (moving faders, for instance). That's ok, but there's a "middle ground" where you're just using the CPU "a fair bit" and maybe you want the controls to be more responsive. Setting audio device RT priority at 70 for instance seems like a nice compromise of being able to get the lowest possible latency and also good responsiveness even when the CPU is being slammed with lots of plugins (at the expense of the odd xrun). Then when I set my buffer to 4 blocks of 128, it's solid up to 100% CPU and responsive.

Also I played around changing Reaper's RT priority. It seems keeping it lower than the audio card's RT priority means fewer xruns when you're pushing things to extremes (super low latency and highest CPU use), but Reaper feels less responsive at the same time. If you increase Reaper's RT priority it will be more responsive but then it can have more xruns. I tried setting the audio device to 95 and Reaper to 80 (then 70, etc.) but it seems the best balance was to keep reaper around 40 as recommended in the settings dialog (then put the audio device's priority around 70).

[JamesPeters]

Originally Posted by lilith93

I have my soundcard set to a priority of 90 and Jack to 88. Everything below 99 or 98 should be fine. As I'm using Jack all the time Reaper is running with the priority of Jack. My sample rate is typically 528 as I don't need ultra low latency. I prefer a cooler CPU

Based on your latest issue that you posted about on another thread, I think your JACK settings may require some adjustment, either the priority or buffer size (or both). That buffer size is actually 4 periods of 528 samples/frames.