Basically #rtcirqus solves the following #rtirq issue:

https://github.com/rncbc/rtirq/issues/12

/5

The main difference between #rtcirqus and rtirq is that rtcirqus allows you to set the real-time priority of a thread based on ALSA card names. rtirq works differently, it sets the real-time priority based on kernel module names. So with rtcirqus you can be sure the desired audio interface gets the desired real-time prio, with rtirq you're prioritising all the devices that make use of a specific kernel module (xhci_hcd, snd_hda_intel)

/4

Regarding threaded IRQs, enabling those by itself doesn't change anything. You will need to configure those threaded IRQs after you've enabled them. Tools that can do this are #rtcirqus or rtirq. You could also do this manually by using the `chrt` command on the threaded IRQ process.

Modern systems use MSI(-X) interrupts though (Message Signaled Interrupts) so shared IRQs should be something of the past. On those systems there's very little gain in prioritising threaded IRQs.

/3

@ambientspace You don't need a low-latency or realtime kernel unless you're doing audio that demands very low round-trip latencies (below 10ms).

Rtirq can help but I don't think it can deal with modern systems using Message Signaled Interrupts (MSI or MSI-X). For systems with MSI-X interrupts #rtcirqus might be an alternative.

As for Milliseconds, it relies on an underlying tool, #rtcqs that in its turn links to wiki.linuxaudio.org. It's command line only but might come in handy sometimes.