You are here

rtirq - correct defintion of RTIRQ_NAME_LIST in /etc/default/rtirq ???

Hello Rui

The standard entry for RTIRQ_NAME_LIST installed with Ubuntu 14.04LTS is:

RTIRQ_NAME_LIST="rtc snd usb i8042"

KXStudio recommends:

RTIRQ_NAME_LIST=“firewire snd usb i8042”

As I am currently testing a firewire audio device whereby the ffado stream is being tripped up by unwanted xruns, would adding "firwire" to the begining of the list bring any benefit? Or is this redundant with the current kernel firewire drivers?

Also, what is the function of rtc? Do I need it? Should it have the highest priority?

Cheers, Simon

Forums: 
rncbc's picture

hi Simon,

yes, "firewire" used to make sense for devices driven by the FFADO drivers.

however, i've been told that recent kernels are pouring support for firewire devices as well, but then, they will be driven by the ALSA infra-structure, so the particle to contemplate in RTIRQ_NAME_LIST is still "snd".

re. "rtc" stands for the real-time clock devices. tbh. i don't quite remember why it was set to highest priority anyway; at the time it was being created, during the voluntary_preempt kernel days, which would lead to preempt_rt a bit later, i guess it was Ingo Molnar's suggestion: we were measuring kernel latency timings and rtc made sense to have top priority back then. maybe it's no big deal if one keeps it or drops it--i don't have it myself on my /etc/sysconfig/rtirq for quite some time, if you want to know ;)

hth.
cheers

Simon Lewis's picture

Hi Rui

As always, many thanks for your prompt and professional replies.

Is there a reason why "snd" appears in both RTIRQ_NON_THREADED="rtc snd" and RTIRQ_NAME_LIST="rtc snd usb i8042"?

Does this mean the snd devices have an IRQ but are not threaded? Should this also apply to firewire devices?

Cheers, Simon

rncbc's picture

entries in RTIRQ_NON_THREADED only applies to VOLUNTARY_PREEMPT kernels; it's a no-op on anything else;

tbh. i don't event know if it's still a valid option for a kernel configuration nowadays, so don't bother with it at all.

cheers

Simon Lewis's picture

Hi Rui

This is proving to be tricky....

Want I want to do is use the firewire audio interface (Focusrite Saffire PRO 24) most of time, when this is not available fall back on USB audio interfaces (Behringer U-Control UCA222 and Roland UM-1) and occasionally be lazy and use the internal loudspeakers for playback.

On this naked KXStudio 14.04 installation the following IRQs are available:

simon@simon-Precision-M4300:~$ sudo cat /proc/interrupts
CPU0 CPU1
0: 20606 22313 IO-APIC-edge timer
1: 112 157 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc0
9: 0 1 IO-APIC-fasteoi acpi
12: 75 74 IO-APIC-edge i8042
14: 271 232 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
17: 5341 5501 IO-APIC-fasteoi ata_piix
19: 43 48 IO-APIC-fasteoi firewire_ohci, yenta
20: 3260 3567 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb5
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb6
22: 41 35 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7
45: 25580 27063 PCI-MSI-edge nouveau
46: 102 103 PCI-MSI-edge snd_hda_intel
47: 13842 3226 PCI-MSI-edge iwl3945
48: 2 1 PCI-MSI-edge eth0
NMI: 40 37 Non-maskable interrupts
LOC: 75327 79526 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 40 37 Performance monitoring interrupts
IWI: 4489 6409 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 14314 23074 Rescheduling interrupts
CAL: 444 189 Function call interrupts
TLB: 274 261 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 2 2 Machine check polls
ERR: 0
MIS: 0
simon@simon-Precision-M4300:~$

The firewire interface is on IRQ 19 (firewire_ohci driver) - a built in 1394 host controller sitting on a card bus (yenta driver). I am guessing the card bus controller and 1394 host controller are in the same chip.

With all audio interfaces connected (which is not the normal case) the following ALSA compatible sound cards are identified:

simon@simon-Precision-M4300:~$ sudo cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xfebfc000 irq 46
1 [Loopback ]: Loopback - Loopback
Loopback 1
2 [CODEC ]: USB-Audio - USB Audio CODEC
Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.1-2, full speed
3 [UM1 ]: USB-Audio - UM-1
EDIROL UM-1 at usb-0000:00:1d.0-1, full speed
simon@simon-Precision-M4300:~$

The following modules are in use:

simon@simon-Precision-M4300:~$ sudo cat /proc/asound/modules
0 snd_hda_intel
1 snd_aloop
2 snd_usb_audio
3 snd_usb_audio
simon@simon-Precision-M4300:~$

The loopback is installed by KXStudio by default and provides an ALSA-JACK bridge for routing jackd non-compliant apps like Adobe's flash player into JACK.

In theory according to http://subversion.ffado.org/wiki/IrqPriorities I need to assign the RTPRIOs as follows:

  • Realtime clock (rtc0) on IRQ 8 => RTPRIO 90 (clock used to generate timed interupts)
  • Cardbus slot (yenta) on IRQ 19 => RTPRIO 88 (higher than the audio card on the bus)
  • Firewire module (firewire_ohci) on IRQ 19 => RTPRIO 86
  • U-Control UCA222 (snd_usb_audio) => RTPRIO 84
  • UM-1 (snd_usb_audio) => RTPRIO 82
  • Internal sound card (snd_hda_intel) on IRQ 46 => RTPRIO 80
  • ALSA-JACK bridge (Loopback) => RTPRIO 78

jackd needs to start at RTPRIO 70

Also I need to get sirq-hrtimer, sirq-timer, sirq-tasklet and sirq-sched at the highest RTPRIOs.

My first thought was to set-up /etc/default/rtirq as follows:

RTIRQ_NAME_LIST="rtc0 yenta firewire snd aloop"
RTIRQ_PRIO_HIGH=90
RTIRQ_PRIO_DECR=2
# RTIRQ_PRIO_LOW=51
RTIRQ_RESET_ALL=0
# RTIRQ_NON_THREADED="rtc0 yenta firewire snd aloop"
RTIRQ_HIGH_LIST="hrtimer timer tasklet sched"

The result is:

simon@simon-Precision-M4300:~$ sudo /etc/init.d/rtirq status

PID CLS RTPRIO NI PRI %CPU STAT COMMAND
77 FF 90 - 130 0.0 S irq/8-rtc0
451 FF 88 - 128 0.0 S irq/19-yenta
615 FF 84 - 124 0.0 S irq/46-snd_hda_
31 FF 50 - 90 0.0 S irq/9-acpi
58 FF 50 - 90 0.0 S irq/14-ata_piix
59 FF 50 - 90 0.0 S irq/15-ata_piix
64 FF 50 - 90 0.2 S irq/17-ata_piix
68 FF 50 - 90 0.0 S irq/22-ehci_hcd
69 FF 50 - 90 0.0 S irq/20-ehci_hcd
70 FF 50 - 90 0.0 S irq/20-uhci_hcd
71 FF 50 - 90 0.0 S irq/21-uhci_hcd
72 FF 50 - 90 0.0 S irq/20-uhci_hcd
73 FF 50 - 90 0.0 S irq/21-uhci_hcd
74 FF 50 - 90 0.0 S irq/22-uhci_hcd
75 FF 50 - 90 0.0 S irq/12-i8042
76 FF 50 - 90 0.0 S irq/1-i8042
161 FF 50 - 90 0.0 S irq/19-firewire
176 FF 50 - 90 0.3 S irq/45-nouveau
626 FF 50 - 90 0.3 S irq/47-iwl3945
1225 FF 50 - 90 0.0 S irq/48-eth0
3 TS - 0 19 0.0 S ksoftirqd/0
20 TS - 0 19 0.0 S ksoftirqd/1

simon@simon-Precision-M4300:~$

Note the firewire host controller was left behind...

So second attempt with:

RTIRQ_NAME_LIST="rtc0 firewire snd aloop"
RTIRQ_PRIO_HIGH=90
RTIRQ_PRIO_DECR=2
# RTIRQ_PRIO_LOW=51
RTIRQ_RESET_ALL=0
# RTIRQ_NON_THREADED="rtc0 firewire snd aloop"
RTIRQ_HIGH_LIST="hrtimer timer tasklet sched"

The result is:

simon@simon-Precision-M4300:~$ sudo /etc/init.d/rtirq status

PID CLS RTPRIO NI PRI %CPU STAT COMMAND
77 FF 90 - 130 0.0 S irq/8-rtc0
149 FF 88 - 128 0.0 S irq/19-firewire
609 FF 86 - 126 0.0 S irq/46-snd_hda_
31 FF 50 - 90 0.0 S irq/9-acpi
58 FF 50 - 90 0.0 S irq/14-ata_piix
59 FF 50 - 90 0.0 S irq/15-ata_piix
64 FF 50 - 90 0.1 S irq/17-ata_piix
68 FF 50 - 90 0.0 S irq/22-ehci_hcd
69 FF 50 - 90 0.0 S irq/20-ehci_hcd
70 FF 50 - 90 0.0 S irq/20-uhci_hcd
71 FF 50 - 90 0.0 S irq/21-uhci_hcd
72 FF 50 - 90 0.0 S irq/20-uhci_hcd
73 FF 50 - 90 0.1 S irq/21-uhci_hcd
74 FF 50 - 90 0.0 S irq/22-uhci_hcd
75 FF 50 - 90 0.0 S irq/12-i8042
76 FF 50 - 90 0.0 S irq/1-i8042
177 FF 50 - 90 0.4 S irq/45-nouveau
447 FF 50 - 90 0.0 S irq/19-yenta
620 FF 50 - 90 0.5 S irq/47-iwl3945
1209 FF 50 - 90 0.0 S irq/48-eth0
3 TS - 0 19 0.1 S ksoftirqd/0
20 TS - 0 19 0.1 S ksoftirqd/1

simon@simon-Precision-M4300:~$

Now the yenta controller is left behind...

Also, the usb audio devices were not picked up, even though "snd" is in the list.

Any ideas?

Cheers, Simon

rncbc's picture

hi Simon,

all seems working according to plan ;)
take note that rtirq:

a. only honors one and only one driver thread per IRQ line, so that you'll have to choose either "yenta" or "firewire". you cannot have both, as they already share the same IRQ service line (19);

b. the "snd" particle applies to PCI audio devices; "usb" is generic for (all) USB host controllers and applies for all USB devices including audio ones; if you want specific ports only to get prioritized, then use the respective trait (eg. "usb1", "usb2", etc. you'll have to dig which one exactly is right, coz it depends on which physical USB host port is the device plugged in).

hth.
cheers

Simon Lewis's picture

Hi Rui,

Many thanks for your prompt reply. Please can you clarify the following just to get the small details right.

1. If I pick "yenta" in RTIRQ_NAME_LIST does this result in both "yenta" and "firewire" being handled with the same RTPRIO as they share the same interupt?

2. Is there a tweak that can be included in /etc/default/rtirq to move either yenta or firewire to another IRQ?

3. What is the best command line to sort out the usb ports? This laptop seems to have 2 or 3 internal devices per usb slot.

4. Can the the usb names to be used in /etc/default/rtirq be given a sub-name for fine differentiation?

5. Finally, what name formats does RTIRQ_NAME_LIST accept (and which command line instructions find them)?

Sorry for all the questions.

Cheers, Simon

rncbc's picture

1. If I pick "yenta" in RTIRQ_NAME_LIST does this result in both "yenta" and "firewire" being handled with the same RTPRIO as they share the same interupt?

no. only one, either "yenta" or "firewire" gets the prize.

2. Is there a tweak that can be included in /etc/default/rtirq to move either yenta or firewire to another IRQ?

no. that is not the scope of rtirq. in fact i don't really know if that's possible at all at the hardware(BIOS) or kernel level.

3. What is the best command line to sort out the usb ports? This laptop seems to have 2 or 3 internal devices per usb slot.

lsusb is my first bet; try that and match with what /proc/asound/cards lists; most probably you'll be looking for the bus major number.

4. Can the the usb names to be used in /etc/default/rtirq be given a sub-name for fine differentiation?

no. you're stuck with USB host controller port(bus) numbers, sorry.

5. Finally, what name formats does RTIRQ_NAME_LIST accept (and which command line instructions find them)?

there are only two special keywords: "snd" and "usb", which you know their meaning already; all other options might be sourced as a substring from what is found in the last and right-most column of the /proc/interrupts list.

hth.
list

Simon Lewis's picture

Hi Rui

Just out of interest I was able to assign different priorites to devices sharing the same IRQ with rtctl after deinstalling rtirq.

The hardwire irqs are now prioritised as follows.
<code>simon@simon-Precision-M4300:~$ rtctl show hardirq
31 85 FF [irq/9-acpi]
58 85 FF [irq/14-ata_piix]
59 85 FF [irq/15-ata_piix]
64 85 FF [irq/18-ata_piix]
68 85 FF [irq/22-ehci_hcd]
69 85 FF [irq/20-ehci_hcd]
70 85 FF [irq/20-uhci_hcd]
71 85 FF [irq/21-uhci_hcd]
72 85 FF [irq/20-uhci_hcd]
73 85 FF [irq/21-uhci_hcd]
74 85 FF [irq/22-uhci_hcd]
75 85 FF [irq/12-i8042]
76 85 FF [irq/1-i8042]
77 90 FF [irq/8-rtc0]
147 88 FF [irq/19-firewire]
176 85 FF [irq/45-nouveau]
435 89 FF [irq/19-yenta]
600 85 FF [irq/46-snd_hda_]
611 85 FF [irq/47-iwl3945]
1150 50 FF [irq/48-eth0]
simon@simon-Precision-M4300:~$ </code>

The rtgroups that I used to do this are as follows:

<code>kthreads:*:1:*:\[.*\]$
watchdog:f:99:*:\[watchdog.*\]
migration:f:99:*:\[migration\/.*\]
softirq:f:70:*:\[.*(softirq|sirq).*\]
softirq-net-tx:f:75:*:\[(softirq|sirq)-net-tx.*\]
softirq-net-rx:f:75:*:\[(softirq|sirq)-net-rx.*\]
softirq-sched:f:1:*:\[(softirq|sirq)-sched\/.*\]
rpciod:f:65:*:\[rpciod.*\]
lockd:f:65:*:\[lockd.*\]
nfsd:f:65:*:\[nfsd.*\]
hardirq:f:85:*:\[(irq|IRQ)[\-_/].*\]
cardctl:f:88:*:\[irq/19-firewire]
hostctl:f:89:*:\[irq/19-yenta]
timer:f:90:*:\[irq/8-rtc0]</code>

Format is: <groupname>:<sched>:<prio>:affinity:<regex>
sched 'f' is fifo otherwise '*' (leave alone) is cfs

The prcocess names that can be chosen can be found with:

<code>$ ps -eo cmd</code>

The synchronisation between ffado and jackd still keeps slipping due to xruns but the number of xruns has however dropped significantly.

I guess I need to tweak the settings of the rtgroups - I haven't found any suggestions using rtctl in audio production workstations...

Cheers, Simon

Add new comment