Main menu
You are here
rtirq update - 2019 edition
29 January, 2019 - 18:00 — rncbc
rtirq-20190129.tar.gz
rtirq-20190129-37.src.rpm
rtirq-20190129-37.noarch.rpm
Hello there!
Another year, another rtirq update:
- Restart rtirq service after resume from suspend (by Térence Clastres).
- Fix for some Intel internal and USB stuff (by Samuel Pelegrinello).
- Version 20190129.
Home-brew packages are available here:
rtirq-20190129-37.src.rpm
rtirq-20190129-37.noarch.rpm
Again take note that the rtirq init-script/systemd-service makes sense only on real-time preemptive (PREEMPT_RT) or threadirqs enabled GNU/Linux kernels.
Cheers && Enjoy!
Comments
strange rtirq behaviour
I cut and pasted this from a post I made in Ask Fedora:
I have installed F33 on a X230 laptop, as I need a portable solution for an audio engineering project I am working on.
Part of the process is to install and enable rtirq, which enables me to set interrupt priorities for real time audio processing/production.
This works as normal, except during suspend, when the things do not work quite as expected, snd_hda is relegated to a lower priority. This is the internal intel audio which I am currently using.
Fine, one would think a simple rtirq restart should set that right, but it doesn’t. What happens is that enp0s25, the lan (not being used as the laptop is on wifi) is assigned whatever priority should be assigned to snd_hda.
I have tried many experiments, and the same result. Whatever priority snd_hda is assigned in the rtirq config. file is assigned to enp0s25 after rtirq restart.
Systmctl restart rtirq - same result.
Only a reboot will set the correct priorities again.
This looks like a bug in rtirq? Any ideas?
re. strange rtirq behaviour
check your /proc/interrupts: your enp0s25 and snd_hda might be sharing the same IRQ line...
also check your /etc/rtirq.conf, make sure you have RTIRQ_NAME_LIST="snd_hda_intel i8042" in your case--the once default of "snd usb i8042" might just not be a good one for you.
byee
Add new comment