[PlanetCCRMA] The JACK Story (or "The State of (the Union) JACK" speech)

[Fernando Lopez-Lezcano]

On Mon, 2009-11-23 at 14:09 -0700, David Nielson wrote:
> I want to make sure I understand all this correctly.
> 
> 1. When we are talking about "priority" in this context, are we talking 
> about which processes have permission to preempt which other processes? 
> A higher priority task can preempt a lower priority task but not vice-versa?

Yes, with a caveat. The kernel has several scheduler policies. I'm
pretty much always talking about the "real-time" policies (SCHED_FIFO,
SCHED_RR) which always have priority over SCHED_OTHER no matter what the
priority of the SCHED_OTHER processes are. So SCHED_FIFO and SCHED_RR
_always_ preempt normal tasks - by default programs you run and most of
the operating system runs with the SCHED_OTHER policy. 

Some threads in jack run with SCHED_FIFO or SCHED_RR when you use the
"-R" command line option and that's what needs special permissions. 

(for details see man sched_setscheduler)

> 2. When we talk about "kernel threads" (rtc) are we talking about things 
> like the scheduler, which should never ever be preempted, or are we 
> talking about things like disk I/O?

hmmmm, I don't think the scheduler counts as a "process". Otherwise you
are right, in an rt patched kernel (not the regular Fedora kernel) all
irq's (interrupt service requests) coming from the hardware peripherals
are serviced by code that runs with a real-time policy (plus some other
important stuff in the kernel, timer management threads is one, I
think). 

> 3. Does the system in place distinguish between critical kernel 
> processes, like the scheduler, and things that a user might want to put 
> off until later, like disk I/O? (The reason I ask is that, with my 
> setup, I can get 128x2 to be rock-solid *unless* there is an SD card in 
> my computer's SD card reader, and if I am copying a file from the SD 
> card to the hard disk, I get xruns of 40ms (forty milliseconds, REALLY!) 
> so there is obviously something in the I/O that should get preempted but 
> doesn't.)

The answer to this is a bit complicated. The kernel scheduler (I think
the default is the CFS, the "Completely Fair Scheduler") does not know
what the user wants. It just juggles tasks according to the policy,
priority and many other things - which I guess can be configured by the
user :-) 

In your particular case it is difficult to know why you get xruns
without more data. What kernel are you running? If an rt kernel are you
optimizing interrupt priority with rtirq? If so, at what priority are
the jack rt threads running? 

If it is all optimized then there's a preemption point (or points) in
the sd card driver that should be taken care of in the rt patch... a bug
probably. 

> 4. Would rt permissions for regular users be unacceptable to regular 
> Fedora because of the possibility of a user crafting or unintentionally 
> running a task with a high priority which then crashes, potentially 
> taking down the entire system?

It is not that it can crash, quite the reverse. An SCHED_FIFO or
SCHED_RR process can only be preempted by another SCHED_FIFO or SCHED_RR
process with higher priority. So a program, by mistake or design, can
enter into a loop and not yield the CPU at all - and if there is no
other SCHED_FIFO or SCHED_RR that premmpts it and hopefully kills it
(there are several programs that can do that - watchdog timers) all user
processes will be just waiting for a chance to get at the CPU and will
never get it. You then have a locked machine that technically has not
crashed but is useless :-) 

> 5. Does it really make that much difference? I know software I can write 
> and run on a non-rt kernel as a regular user that basically takes down 
> the entire system for everyone. So what's the big deal?

See above, that's called a denial of service attack. Any user with
access to real-time scheduling policy could do that. 

> 6. If I understand correctly, the ability of a user to start 
> high-priority tasks depends on their membership in the jackuser group. 

In Fedora, yes. After you have installed the Planet CCRMA jack you don't
need to do that, all users have access by default. 

> Would it be acceptable to the Fedora people to have a "audio 
> configuration wizard" applet (forgive me; I grew up with Windows) that 
> requires the root user to grant membership to the jackuser group, and 
> includes a Big Scary Warning about the potential for disaster?

I guess the regular group membership gui would be enough for that (don't
know what it is these days). 

> (I think it's probably safe to assume that in most DAWs, the end user 
> and superuser are the same person, but for the average Fedora 
> installation, that's an unsafe assumption?)

-- Fernando