4 Feb
2007
4 Feb
'07
11:40 p.m.
On 2/4/07, Ken Restivo <ken(a)restivo.org> 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