9 May
2012
9 May
'12
3:03 a.m.
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.
9 May
9 May
4:38 p.m.
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(a)rncbc.org
4:45 p.m.
So this explains why I had to reboot.
$ grep RTIRQ_RESET_ALL /etc/default/rtirq
RTIRQ_RESET_ALL=0
:)
Ralf
4:50 p.m.
On 05/09/2012 04:38 PM, Rui Nuno Capela wrote:
On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
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
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
7:44 p.m.
New subject: rtirq, kernels >= 3.2 and udev & pm
On 05/09/2012 07:50 AM, Robin Gareus wrote:
On 05/09/2012 04:38 PM, Rui Nuno Capela wrote:
Cool....
I'm attaching my first try at using a pm-utils script. This script saves
the priority state of all irq* processes and restores them after a
resume. It only restores the priority for processes that still exist
after the resume, and will do nothing for new processes (ie: you plugin
a usb card while the computer is sleeping). That would be taken care by
my previously posted udev script which would change priority of newly
inserted soundcards. I put 05rtirq it in /etc/pm/sleep.d/ directory...
it seems to be working fine in my laptop.
-- Fernando
On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano
wrote:
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 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) ?
8:23 p.m.
On 05/09/2012 07:38 AM, Rui Nuno Capela wrote:
On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
Yes, probably not on par with the times as when using threaded irqs they
run by default SCHED_FIFO and with priority = 50 (I don't know if the
priority is fixed or can be changed by, say, a kernel boot parameter).
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:)
I like the idea of using udev for setting priorities of soundcard
interrupts as that allows you to run with the least amount of high
priority processes (only for the cards actually present). In particular
for usb cards only the usb irq that corresponds to the card needs to be
raised and then it returns to normal when the card is unplugged.
-- Fernando
4519
days inactive
4519
days old
linux-audio-user@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Fernando Lopez-Lezcano -
Ralf Mardorf -
Robin Gareus -
Rui Nuno Capela