[alsa-devel] Xrun stack trace for 1010LT

[John Rigg]

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