linuxaudio.org

On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:

quoted text
> 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.

quoted text
> -- 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@rncbc.org

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user