On 05/09/2012 04:38 PM, Rui Nuno Capela wrote: > 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) ? indeed. that works just fine here since over 2 years. the scripts I use to retain jackd2 & qjackctl during suspend/resume cycles are available from http://gareus.org/wiki/jack2contol for dynamically switching audio-interfaces I settled on dbus (and not udev, since jackd runs as user): http://gareus.org/blog/jack2dbus > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
