Try again with JACK 0.99.48. It's in CVS now, but you probably need this tarball to get around the dreaded SourceForge anon CVS lag...
http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
Thanks it finally ran to completion. By the way the patch you sent with the test suite did not apply so I had to do it manually (booraroom..)
The results I get with these versions are a lot more stable. But,
there are still some puzzles about the scheduling. Do you distinguish
different SCHED_ISO priorities?
It was not clear whether that would be required or not. This is why testing is so critical because if you are having latency issues it wouldn't be a problem of getting cpu time since your cpu usage is well below the 70% limit.
JACK runs with three different SCHED_FIFO priorities:
(1) The main jackd audio thread uses the -P parameter. The JACK default is 10, but Rui's script sets it with -P60. I don't think the absolute value matters, but the value relative to the other JACK realtime threads probably does.
(2) The clients' process threads run at a priority one less (59).
(3) The watchdog timer thread runs at a priority 10 greater (70).
(4) LinuxThreads creates a manager thread in each process running one level higher than the highest user realtime thread priority.
Since I (finally) have it running at this end at last I'll do some benchmarking of my own to see how (lack of) priorities affects SCHED_ISO. If it is inadequate, it wont be too difficult to add them to the design. The problem with priorities is that once you go over the cpu limit everyone suffers equally; but that's a failsafe that you shouldn't actually hit in normal usage so it probably doesn't matter... Hmm come to think of it, it probably _is_ a good idea to implement priority support afterall.
Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
