When I run
latencytest0.42-png from sbenno(a)gardena.net, I get about 99% sub
2ms latency. But jack still complains of xruns of about 50ms. There's
something here I'm simply failing to understand... but I don't know where to
Are you running JACK as root with "-R" or with "-R --asio"? Do these
50ms
xruns occur even if you don't have any clients connected? If that's not
the case, what client apps you have tested with? Also, do these xruns
happen all by themself, or are you doing something at the same time (maybe
moving windows or something). Does the HD led go on when the xrun occurs
(kernel maybe syncing its caches)? What kernel, with low-latency patches,
with pre-emption enabled or not?
and finally, a general warning:
JACK tests a lot more of the kernel than benno's latencytest program
or andrew morton's rtc-based tester. that is because JACK requires not
only rapid interrupt servicing and return to user space, it also
requires absolutely correct scheduling between user space contexts
using pipe write(2) and poll(2) calls. if all JACK clients were
in-process, its performance characteristics would be identical, more
or less, to latencytest. but nothing except the ALSA client/driver are
in-process right now, and so if the kernel ever goofs up scheduling,
then whatever the characteristics of the clients, things will break.
the bad news is that the kernel (at least as of 2.4.19) *does* goof up
the scheduling. if anyone wonders why i'm so cranky today, its because
i am trying to discover why it does this, and to see if it can be
fixed without compiling and booting 2.5 (which probably doesn't behave
the same way).
with latencies above 10ms, you will likely not notice the problem i am
debugging. with latencies below that number, especially way below, at
least on an SMP system, you will not JACK to run reliably with
2.4.19+ll. for now. hopefully, this will be fixed soon.
none of the above applies to a system with just jackd+alsa
running. such cases are immune to the scheduling bug i am looking at,
and are more likely to be caused by other system activity that
involves improperly tuned subsystems (such as IDE drives).
--p
