On Tue, 2004-03-23 at 06:13, Ross Vandegrift wrote: > On Tue, Mar 23, 2004 at 11:44:24AM +0100, Kjetil Svalastog Matheussen wrote: > > This is very interesting. It says that preempt have no influence > > on the worst-case latency. In other words, this means that > > preempt in theory is useless regarding use of realtime audio. > > Has anyone tried audio work with 2.6 and preempt *off*? I've been using > 2.6 some, with preempt on and I'm seeing exactly the same kind of > behaviour as the original email in the thread reports - compiles take > twice as long and disk latency kills interactivity whenever something > loads a program/file. I basically went back to 2.4+lowlatency for audio > work, but I wonder if anyone's tried 2.6 without preempt? I just did and it does make a significant different in my tests (I have not tested yet compiling performance). Here are some results. These kernels are rebuilds of Arjanv's test packages, which can be found at: http://people.redhat.com/arjanv/2.6/ The differences are preemption, Takashi Iwai's patches for low latency (as outlined in http://kerneltrap.org/node/view/2702), some additional low latency patches for the drm modules, oss soundcore enabled (for OSS emulation) and proper options enabled for including the LSM realtime kernel module. These tests were done on my Sony laptop (GRX580, radeon video chipset) with a full Fedora Core 1 install plus Planet CCRMA, using latencytest 0.52 and the latency-test kernel module. a) preempt enabled, Takashi's patches included, x11 sucks... http://www-ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.279.ll.ccrma/ b) preempt enabled, added tweaked radeon low latency patch, much better: http://www-ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.279.ll.ccrma.radeon/ c) preempt disabled, with Takashi's and radeon patches: http://www-ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.286.1.ll.radeon/ d) same as c), with preempt enabled again: http://www-ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.286.2.ll/ e) same as d), without loading the xfree86 dri module: http://www-ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.286.2.ll.nodri/ Caveats: FC1 qt + dri + 2.6.4 + SCHED_FIFO = hanging machine, as reported a while back. Yuck. Turning off dri solves this one at the cost of no acceleration. With all the above I'm able to run Jack with SCHED_FIFO and no xruns in a short test run at 64x2 (with a background task tar'ing /usr to a file). But with DRI off, Qjackctl and some real Jack applications I do get xruns even at 128x2, I guess my cpu is maxing out... Has anyone found a workaround for the dri problem? -- Fernando
