rtirq with udev-rtirq?

[funkmuscle]

Rtirq or udev-rtirq or do they work together?

[Jack Winter]

They are independent, though I can't guarantee which would have precedence on boot.

All the utility does is change the priority of the soundcard interrupt when one is detected on boot/hotplug.

rtirq can set other priorities too, and on one of my systems the system returns the wrong priority for one onboard soundcard, this would also be a valid reason to use both.

[funkmuscle]

They are independent, though I can't guarantee which would have precedence on boot.

All the utility does is change the priority of the soundcard interrupt when one is detected on boot/hotplug.

rtirq can set other priorities too, and on one of my systems the system returns the wrong priority for one onboard soundcard, this would also be a valid reason to use both.

thanx Jack

[gimmeapill]

If you don't need hotplugging, I don't see much reason to use udev-rtirq over rtirq which is a bit more configurable.
If you do need to plug / unplug your high perf audio interface between reboots, then it makes perfect sense (might be tricky to get working properly though).

[funkmuscle]

If you don't need hotplugging, I don't see much reason to use udev-rtirq over rtirq which is a bit more configurable.
If you do need to plug / unplug your high perf audio interface between reboots, then it makes perfect sense (might be tricky to get working properly though).

what about if I have both? Would that be a problem?

[gimmeapill]

Well, not sure.
My gut feeling is that having redundant applications running with root privileges and doing kernel level magic is probably not the safest scenario
You could possibly have one undoing what the other just did in a happy loop?

[funkmuscle]

Well, not sure.
My gut feeling is that having redundant applications running with root privileges and doing kernel level magic is probably not the safest scenario
You could possibly have one undoing what the other just did in a happy loop?

Yeah I had a feeling something funky could happen so I think I'm going to remove one of them. Thanks man.

[Jack Winter]

IMO there ought to be no conflict. udev-rtirq runs when a device is added or removed (which means it runs on boot too), rtirq runs once on boot (normally). If they change priorities of the same soundcard interrupt, then configuring them to use the same priority ought to work well. I could see a reason to use just rtirq as it can change the priority of other things than the soundcard, though I'm personally convinced that this is needed, the drawback being that you lose the hotplug support. udev-rtirq ought to be able to handle it all alone, if all you want is to change the priority of the soundcard interrupts. Hope this is clear enough

[funkmuscle]

IMO there ought to be no conflict. udev-rtirq runs when a device is added or removed (which means it runs on boot too), rtirq runs once on boot (normally). If they change priorities of the same soundcard interrupt, then configuring them to use the same priority ought to work well. I could see a reason to use just rtirq as it can change the priority of other things than the soundcard, though I'm personally convinced that this is needed, the drawback being that you lose the hotplug support. udev-rtirq ought to be able to handle it all alone, if all you want is to change the priority of the soundcard interrupts. Hope this is clear enough

yep both y'all are making sense.. will try with both for a while to see what happens.

[Jack Winter]

Which thread(s) do you want to change the priority of?

[funkmuscle]

Which thread(s) do you want to change the priority of?

The rtirq been doing it's job for my usb interface. I was just curious about the difference and which would be better and if they needed to work together as if the udev was an upgrade or an addition.