Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> 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..)
Oops! Sorry. I generated those by hand using some rather crude `diff -u .... >> xxx.diff' commands. We should just add Rui's latest version to JACK CVS. > 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... I'd be surprised if we're hitting it in this test. AFAICT, our "Average DSP Load" should approximate your CPU limit. That's running in the 30% to 40% range. Is there any way to verify this? Is your running average readable in /proc/sys/kernel somewhere? We do need to test that the system degrades gracefully when the CPU is overloaded. That *will* happen (the dreaded P4 float denormal problems quickly come to mind). At some point, the user should be allowed to choose how much CPU to consume, possibly shutting down plugins as needed. > Hmm come to think of it, it probably _is_ a good idea to implement > priority support afterall. Hard to say for sure without trying it. These threads are dealing with a realtime cycle that is smaller than normal scheduler time slices. Getting all the work done is important. But, getting it done in the right order might make a difference for important statistics like Max Delay. -- joq - 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/
