Hyper Low-Latency Audio with a Real-Time Kernel (video)

[studio32]

http://www.linuxjournal.com/video/hyper ... ime-kernel

[raboof]

The video shows the following:
* recording some stuff with a kernel without realtime patches gives xruns
* download the rt-patches, patch a kernel source and compile it
* download, compile and install set_rlimits
* configure set_rlimits to give rt-priority to jackd and ardour
* observe that the xruns are gone

As for installing a kernel with the rt-patches installed, I'd suggest first checking if there aren't pre-tuned packages available for your distribution, as described here.

set_rlimits looks useful: looks like you can configure nice and rtprio values per user per process. The downside, however, is that you must start every tool as 'set_rlimits myapplication' instead of just 'myapplication'. That seems like quite a hassle.

How do you guys set the rtprio of your applications?

[thorgal]

at least in all debian based OSes, you don't use set_rtlimits, you use the PAM security module (which the guy mentions briefly in his video) and tune /etc/security/limits.conf
In my DAW, I have this setting:

@audio - rtprio 99
@audio - memlock unlimited
@audio - nice -19
which globally (system-wide) gives the unix group audio the privileges set_rtlimits manually gives per process.

It's a nicer way than set_rtlimits.

Another interesting thing for the purists : the init script /etc/init.d/rtirq where you can configure IRQ thread priority.

My rtirq conf (in /etc/default/rtirq for debian systems) looks like this :

-------------------------
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd i8042 hdsp"

# Highest priority.
RTIRQ_PRIO_HIGH=99

# Priority decrease step.
RTIRQ_PRIO_DECR=2

# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=1

# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"

# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
RTIRQ_HIGH_LIST="softirq-timer softirq-hrtimer"
-----------------------
it is important that the softirq-*timer get a high prio as well (these are process threads created in systems that run a RT-patched kernel only).

[raboof]

at least in all debian based OSes, you don't use set_rtlimits, you use the PAM security module and tune /etc/security/limits.conf
In my DAW, I have this setting:

@audio - rtprio 99

If I understand this correctly, this merely specifies that users in the audio group are *allowed* to assign priorities up to 99 to processes - but they will not, by default, get those priorities.

How are applications assigned realtime priority? I see jackd has '-R' and '-P' options, but even when I use those "ps -eo pid,rtprio,user,group,comm | grep jack" suggests jackd is still running without any extra priority.

(yes, I set up /etc/security/limits.conf and am in the audio group).

It's a nicer way than set_rtlimits.

Being able to configure the rtprio on a per-process basis seems elegant, but I'm not sure how this is done with PAM normally. Would like to find out .

set the IRQ thread prio

I really must check that out someday - looks like it works a bit different on ubuntu, as there is no mention of RTIRQ in all of my /etc...

[thorgal]

as far as I know, the realtime priority sched is reserved for certain process threads, e.g. running the qjackctl GUI at high prio does not make sense, but allowing the jackd audio thread RT prio makes more sense. SO it could be that you see that the overall process you launched does not exhibit the rt prio bit, but the thread process that is relevant for low latency does.

[thorgal]

probably some private ubuntu repos : http://ppa.launchpad.net/rzr/ubuntu/pool/main/r/rtirq/

[raboof]

as far as I know, the realtime priority sched is reserved for certain process threads, e.g. running the qjackctl GUI at high prio does not make sense, but allowing the jackd audio thread RT prio makes more sense. SO it could be that you see that the overall process you launched does not exhibit the rt prio bit, but the thread process that is relevant for low latency does.

Ah indeed: when I tell 'ps' to show each thread, it shows some threads (one in qjackctrl even) are given rtprio:

Code: Select all

$ ps xHo pid,rtprio,user,group,comm | grep jack
  949      - arnouten arnouten qjackctl
  952      - arnouten arnouten qjackctl.bin
  952     49 arnouten arnouten qjackctl.bin
24063      - arnouten arnouten jackd
24063      - arnouten arnouten jackd
24063      - arnouten arnouten jackd
24063     60 arnouten arnouten jackd
24063     50 arnouten arnouten jackd

[raboof]

indeed rtprio still needs packaging in Ubuntu