On Fri, Dec 05, 2008 at 08:11:36AM -0800, Pete wrote:
So even if the kernel is not a RT kernel, processes can run with real time priority? How is this so? From what ive read about the RT kernel it sounds like the kernel has to cooperate with the processes running on the system to allow a process to awaken (on an interrupt for instance). Otherwise the kernel will be stuck in some non interruptable state for some time, blocking the interrupt from being serviced - is that wrong?
If Jack has a way to grab higher priority through some other mechanisim, could I build this into arecord I wonder. I have of course tried nicing the process to very unnice.
nice values are irrelevant to processes with rtprio. Any rtprio process will have priority over any process with just a nice value. jackd -R defaults to rtprio 10 (in a range of 0-99). You can raise that by specifying the value on the command line eg. jackd -R -P80 which would increase it to 80 (usually unnecessary and possibly inadvisable). You can look at what's running with rtprio on your system with ps, eg.: ps -Leo pid,cmd,rtprio
rtprio makes use of SCHED_FIFO or SCHED_RR (as opposed to SCHED_NORMAL). These are static soft realtime scheduling policies provided by the standard kernel. The -rt kernels attempt to get closer to hard realtime. Don't confuse the two.
On the current kernels, a non-root user has to belong to a realtime scheduling group (eg. the audio group) and the kernel config needs to have CONFIG_RT_GROUP_SCHED=y to allow rtprio to be used. The relevant configuration must also be present in /etc/security/limits.conf. There are plenty of articles on the web describing how to set up limits.conf.
John