On Wed, 6 Oct 2004 04:37:17 +0200, Florian Schmidt <mista.tapas@xxxxxxx> wrote: > On Tue, 05 Oct 2004 19:01:30 -0400 > Lee Revell <rlrevell@xxxxxxxxxxx> wrote: > > > > The only 3 xruns happened right when I started the kernel compile. > > > > > > This is 2.6.9-rc2-mm4-VP-S7 > > > > > > > There is absolutely _no way_ that these are kernel-induced. The period > > time is 5ms!!! This kernel should _never_ produce an delay of more than > > 200 usecs. This _has_ to be flaky hardware, or a bug in jackd or in > > your clients. What happens if you run jackd with no clients? > > Hi, > > the kernel does weird things nowadays. I do not get any satisfactory results > with either S8 or S9. I get xruns all over the place [under loads much > lighter than a kernel compilation] although the VP and related settings are > as always. T1 is working smoothly again. I have no idea what caused this > behaviour in S8 and S9. But it feels like a scheduler problem. X11 is much > more jumpy under these kernels and load, too than under S7 and T1 > > So, i would still expect some weirdnesses in VP enabled kernels, since they > are based on the mm tree [which might hold many surprises in itself]. > > But anyways, back to Mark. > > I talked to Mark on irc and he seems to have had SMP enabled on a UP system > [p4 mobile w/o HT according to mark]. OTOH this worked fine on fedora, > right? Also this is a notebook, maybe power saving features play a role. > > One more thing to note. His gentoo system uses a linuxthreads glibc. The > same hardware and kernels are working very nicely on his fedora core system > with CCRMA and VP kernels. > > I suspect some weird interplay of a linuxthreads self built glibc and a > 2.6.x kernel, especially wrt to SCHED_FIFO scheduling. > > One more thing: > > The setups between fedora core and gentoo might differ in what default > services run. Do you [Mark] have any powermanagement daemons loaded? cpu > frequency scaling, etc? I know only little about these issues, since i > basically do not use power management. > > The two things i would recommend to try would be: > > 1] Build a very very barebone kernel for, let's say, 386 architecture. no > acpi no apm, no usb [if possible], no smp, local APIC if he likes. Only > those devices really needed, no dri, etc [but of course with the usual set > of VP features enabled]. > > 2] try a gentoo system with a nptl enabled glibc. Either build one, or maybe > get some live cd based on gentoo which fulfills the requirements. See if the > problems persist. Or try some third distribution with nptl libc and slap a > VP kernel on it. If it works fine, your gentoo system is b0rk3n in some way. > > flo > > p.s. which jack version btw? > Hi all, OK, Last evening and this morning I have made good headway. It appears that the main culprit was ACPI support, or some part of it. With most of the ACPI stuff now disabled in the kernel build I am able to run jack with no clients attached, as a root or user with the lsm module modprobed, at p=8, n=2 for over 1 hour with no xruns. If my calculations are correct this would be a latency of less than 0.5mS! My current kernel is 2.6.9-rc2-mm4-VP-S7-lsm-UMP-noACPI: - 2.6.8 from kernel.org - 2.6.9-rc2 patch - 2.6.9-rc2-mm4 patch - voluntary_premption-S7 patch - realtime-lsm patch I've built it with most everything I can find that I do not absolutely need turned off. I'm non-SMP, ACPI mostly gone, and who knows what else along the way. I'll send the .config file to whoever might need it. I am then running the sound card and CDROM interrupts non-threaded and everything else is threaded. In terms of better testing I now need to concentrate on finding an application that run without creating xruns within the application itself. At higher latency values (p=256 for instance) alsaplayer -r -o jack runs pretty well, but as I move to lower latencies I find that alsaplayer deterministically creates xruns at the transistion between every song on a CD. I also tried alsaplayer playing wave files from disk, but I see xruns as it goes from one file to the next also. I want to try using chrt to see if alsaplayer is really getting real-time access, etc. Maybe there are things still not right with the way I'm running it on my box. Is there any other simple app that could play a wave file from, for instance, memory without this sort of problem? I'll certainly be trying out Ardour as a bigger test once I'm more confident of the disk access issues in real-time. I think that 1394 support may not be in good shape in this kernel yet. So, the good news is my Gentoo system is not broken, and that I've hopefully learned a bit and contributed just a little bit more along the way. That said I still have a long ways to go. Cheers, Mark
