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.
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?