On 2/4/07, Ken Restivo <ken@xxxxxxxxxxx> wrote:
On Sun, Feb 04, 2007 at 04:54:01PM -0800, Fernando Lopez-Lezcano wrote:
> It looks like the package was built to use capabilities. I don't know > what jackd does when it does not find the proper capabilities (which > will not be found if you are using pam), whether it still tries to get > SCHED_FIFO or if it just gives up, it looks like the later.
I think we handle that correctly, i.e. go ahead and try to set SCHED_FIFO anyway and use it if available. The current JACK engine implementation fails if -R is selected and realtime scheduling is not available. That changed fairly recently, IIRC, so an older version might continue running in that case.
What the.... I certainly hope not. I thought that was a spurious error message to be disregarded, since jackd definitely *is* running with RT priorities, at least on my machine, it reports: FreeBoB MSG: Streaming thread running with Realtime scheduling, priority 74 FreeBoB MSG: Registering capture port dev1c_MicIn1 left And ps says... PID CLS RTPRIO NI PRI %CPU STAT COMMAND 3423 TS - 0 20 0.0 SLl jackd 3423 TS - 0 24 0.0 SLl jackd 3423 TS - 0 24 0.0 SLl jackd 3423 TS - 0 19 0.0 SLl jackd 3423 FF 80 - 120 0.0 SLl jackd 3423 FF 70 - 110 1.5 SLl jackd 3423 FF 73 - 113 5.6 SLl jackd 3423 FF 73 - 113 5.0 SLl jackd 3423 FF 84 - 124 0.0 SLl jackd 3423 FF 74 - 114 5.4 SLl jackd Although, I just noticed now that some of those jackd threads aren't running with any RT prio at all. And, I also noticed that the little yellow "RT" in qjackctl isn't lit up either... Is that OK? Or is this a problem?
Several JACK threads are not supposed to run RT.
I'm standing by and waiting to hear from the jackd developers before filing this with the Debian bug tracking system... And also waiting to hear back before I go out and blow $400 on a 2.4Ghz CPU....
I can't say what you should do. Looks like it ought to work to me. -- joq
