On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
Hi all (and Rui),
As noted in another thread I found out that the naming of the irq
processes of pci soundcards has changed with kernels >= 3.2 to be
uniform and predictable. That made it possible to change rtirq so that
(at least for pci cards) only the irq process that corresponds to the
soundcard gets an elevated priority - this was not completely reliable
before.
Another nice (very nice I'd say) side effect of this change is that now
udev can be trivially used to change the priorities of soundcards
dynamically. I tested this while running 3.2.16-rt27 on a Fedora 14
system. I removed "snd" and "usb" of the rtirq sysconfig file so that it
would not touch those and rebooted. My hda_intel got the priority I
wanted, inserting (or removing) a usb or a pci-express card with a
Multiface II worked as well. Right now my simple script does not try to
order priorities, it just sets them to a fixed one. But well, it is a
start... Code attached (the udev rule goes into /etc/udev/rules.d/ in my
system)...
This simple script also returns the priority of the usb irq for the
soundcard to 50 (the default) when the card is unplugged, but it does
not check for multiple cards (ie: even if another soundcard is still
using the same irq process it downgrades its priority), this should be
fixed.
Feedback appreciated.
-- Fernando
PS: Another rtirq script in /etc/pm/sleep.d/ could save the current
priorities before a suspend and restore them after a resume - that does
not happen currently.
what about just `rtirq restart` on the sleep.d script (on thaw|resume) ?
warning. there's no state salvage being done on bad old rtirq script. in
fact `rtirq stop` is a plain nop by default, unless RTIRQ_RESET_ALL=1 is
set (cf. /etc/rtirq.conf aka. /etc/sysconfig/rtirq) which makes all
target irq service threads to reset to rtprio=50 but also to "normal"
scheduling class(SCHED_OTHER). might not on par with the times :)
note that `rtirq restart` is actually the same function as `rtirq stop`
immediately followed by `rtirq start`. however, as s the very same irq
service threads are at stake, this whole remark might not be an issue
after all:)
byee
--
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
