On Wed, 6 Oct 2004 04:37:17 +0200, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
On Tue, 05 Oct 2004 19:01:30 -0400
Lee Revell <rlrevell(a)joe-job.com> 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