Bug 795094

*** Bug 795881 has been marked as a duplicate of this bug. ***

(In reply to comment #0)
> The current kernels support IRQ threading with the threadirqs kernel command
> line option.
> 
> This means that Fedora stock kernels can now benefit from more precise RT
> threading priorities by using rtirq.
> 
> I am proposing to pull rtirq into Fedora (currently in CCRMA). The current
> jackuser priority of 20 does not allow for finer grained priority assignment.
> 
> We could either set a default priority for all jack users to something at a
> more reasonable level, or ship in another package an overriding
> /limits.d/*.conf file which places the max priority at something which is a
> little more rtirq friendly. 
> 
> Personally I would like to see the former. If this is the case I would also
> like to propose that we renumber the 99-jack.conf to 95-jack.conf to give a
> little more room for customized limits files

Sorry. i do not understand how this is related with pulseaudio problem in bug 795881.

Sorry, wrong bug - duplicate corrected

Hi Brendan, sorry I have been busy lately. Let me catch up with the mailing list and I'll get back to this.

Okay, can you educate me about rtirq? Does it dynamically set the priorities? Do  we still need to set a default priority? If so, what value do you suggest as reasonable?

I agree about 95-jack.conf.

(In reply to comment #5)
> Okay, can you educate me about rtirq? Does it dynamically set the priorities?
> Do  we still need to set a default priority? If so, what value do you suggest
> as reasonable?

In a kernel booting with threaded irqs active, individual hardware and software irqs for peripherals have individual threads that run SCHED_FIFO. The default priority for the hardware irq threads is 50, for the software irqs 49. This includes either rt patched Planet CCRMA kernels or 3.x Fedora kernels. In the former case the kernel boots with threaded irqs "active" automatically, in the later case it needs a "threadirqs" kernel parameter to be added to the grub boot line. 

Rtirq is a script that reorders the priority of the irq threads. It changes the priority of soundcard related irqs to be higher than all other irqs, and in such a way to there is "priority space" in between those two groups of irqs to accommodate jack and its clients. So, the soudncard irqs have the highest priority, jack and its clients follow and then comes everything else. I forget the particular numbers I'm using but running Jack with a priority of 62 would do the right thing for a Planet CCRMA configured rtirq. 

Regretfully rtirq is not dynamic, it only runs at boot time. 

A better solution would involve detecting udev events and changing the priority of inserted soundcard irqs to the proper one (by, maybe, running rtirq itself). 

The current situation with rtirq is not ideal either, different hardware drivers can share a single irq and while it should be possible to give higher priority to _only_ the one that corresponds to a soundcard, right now (I think) all of the shared irqs get bumped in priority. Last time I looked at this (trying to create a pure udev based solution) I could not find a way to detect which irq corresponds to a soundcard based on the output of ps and the information available to udev (the "name" of the irq thread is arbitrary and not related to udev variables).

Thank you Fernando for the explanation.

Currently we are using this patch on jack
   http://pkgs.fedoraproject.org/gitweb/?p=jack-audio-connection-kit.git;a=blob;f=jack-realtime-compat.patch;h=9a8bdce8449a2e6ea8604bb365de48dcabe0726b;hb=4f18760c85500837b765c3a671a414cc35fb9e18
This sets a priority of 20 for Fedora kernel, and 60 for PREEMPT RT kernel.


So our limits.d file needs to be adjusted in parallel to this patch. I am fine with the changes Brendan suggested, but we need to figure out the correct numbers which will work happily with both Fedora 3.x and CCRMA realtime kernels, together with rtirq.

(In reply to comment #7)
> Thank you Fernando for the explanation.
> 
> Currently we are using this patch on jack
>   
> http://pkgs.fedoraproject.org/gitweb/?p=jack-audio-connection-kit.git;a=blob;f=jack-realtime-compat.patch;h=9a8bdce8449a2e6ea8604bb365de48dcabe0726b;hb=4f18760c85500837b765c3a671a414cc35fb9e18
> This sets a priority of 20 for Fedora kernel, and 60 for PREEMPT RT kernel.
> 
> 
> So our limits.d file needs to be adjusted in parallel to this patch. 

Not necessarily. 

> I am fine
> with the changes Brendan suggested, but we need to figure out the correct
> numbers which will work happily with both Fedora 3.x and CCRMA realtime
> kernels, together with rtirq.

I don't have time right now to really think hard about this, but the first solution that comes to mind is to use the same rt priority for all kernels (and then we can get rid of the aforementioned patch which is also a good thing!). 

A priority of 60 for jack would work just fine for the "normal" kernels ("60" works just as well as "20" in the normal case, and is above the 49/50 priority slot for the threaded irq kernels). 

If we choose a max priority of, say, 90 in our limits.d file, then we need to look at the rtirq configuration so that all irq threads are properly adjusted to work within that upper bound. That would make rtirq work with all kernels, jack's default priority would also work with all kernels and all irq threads would be properly optimized by rtirq if a Fedora kernel is run with the "threadirqs" kernel boot option, or if an rt patched Planet CCRMA kernel is booted for better latency performance.

I don't have any problem with switching the default priority of jack to 60 with the standard kernel. The problem might surface if people from other parts of Fedora don't like this choice. Jack is currently in the critical path [1], and my fear is that such a move could be regarded as selfish. We certainly don't want to get yelled at over this.

What do you think Brendan? You have been quite active lately. Do we have a case here?


[1]  http://fedoraproject.org/wiki/Critical_path_packages

I think portaudio pulls in jack making it critpath.

I think we do have a case here. Its not as if we are changing priorities globally - groups pulse-rt and jackuser are not attributed to normal desktop users by default (nor will the threadirqs kernel command line be present). 

We should probably ask the pam maintainer(s). Reassigning for comment.

Dear pam maintainer, we are considering increasing the rtprio of the user group "jackuser" to ~60. The above discussion points that this is needed for proper audio production use. 

I am sure you know that jack is primary our audio production library and daemon. A Fedora user must explicitly add himself to the "jackuser" group if he wants to use realtime jack. Do you have any comments to add?

I have no problem with that as the users must be added to the jackuser group explicitly.

Thanks Tomas!

Brendan, Fernando, we need to come up with a recipe. Does rtprio=60 and removing the above patch make everyone happy? If not, please come with your suggestion.

(In reply to comment #13)
> Thanks Tomas!
> 
> Brendan, Fernando, we need to come up with a recipe. Does rtprio=60 and
> removing the above patch make everyone happy? If not, please come with your
> suggestion.

IRQ processes in threaded irqs kernels use 49-50. We want to be above that so that we don't have to change the priorities of all those threads. 

Jack itself uses a priority of 20 by default for its own SCHED_FIFO thread. It runs the client audio threads with 5 less priority levels, so by default that would be 15. 

So I think we need a little more space. If we run Jack at 60 then clients would run at 55 (some clients spawn other threads around that value). We could configure rtirq to run the soundcard interrupts at 62, so 65 could be a good number as an upper limit I guess (or even 70 if there is no objection). 

For example, an application I'm working on (basically an ethernet driven high channel cound soundcard) benefits from having some priority space above the soundcard interrupt for upping the network irqs. 

We still need to patch Jack to use 60 as the default priority. That will work on a normal kernel, also on a Fedora kernel with threadirqs on and on Planet CCRMA kernels which always have threadirqs on.

I'm happy to defer to Fernando on this one. 

It would be great if the jack rt priorities are set such that we can retire the need for the rt-priorities package in CCRMA altogether and have the default jack priorities sufficient for both stock and CCRMA kernels (and rtirq of course). Is that possible Fernando?

jack-audio-connection-kit-1.9.8-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/jack-audio-connection-kit-1.9.8-7.fc17

Package jack-audio-connection-kit-1.9.8-8.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing jack-audio-connection-kit-1.9.8-8.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5583/jack-audio-connection-kit-1.9.8-8.fc17
then log in and leave karma (feedback).

jack-audio-connection-kit-1.9.8-8.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.