2 Oct
2004
2 Oct
'04
8:12 p.m.
On Sat, 2004-10-02 at 17:31, Florian Schmidt wrote:
On Sat, 02 Oct 2004 16:58:57 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
I think we have ruled out the kernel. The problem has to be with jackd.
the jack clients, alsa driver, or hardware. Here is the histogram from
amlat 4096 + rtc-debug patch:
rtc histogram:
17 7414
18 36139
19 3320
20 1719
21 1284
22 2480
23 3366
24 3529
25 3583
26 4713
27 9092
28 20543
29 39284
30 68270
31 98382
32 116862
33 127533
34 118842
35 85424
36 51875
37 29316
38 18818
39 16761
40 16627
41 12118
42 7723
43 6542
44 7971
45 9549
46 8433
47 4067
48 1571
49 876
50 840
51 1317
52 2332
53 3535
54 4304
55 4215
56 4604
57 4588
58 3559
59 2464
60 1863
61 1644
62 1203
63 805
64 543
65 445
66 490
67 473
68 438
69 237
70 141
The system was heavily loaded with parallel builds and find *'s, and the
maximum reported latency is 70 usecs.
Lee
Hey,
I have been helping this user get set up with 2.6+VP, and it really
looks like the kernel is not the problem - the maximum latency
reported by Ingo's tracer is under 200 usecs, but there are still
xruns. All my tests show that it should work at 128 or even 64 frames
with this setup. It really looks like jackd or the jack clients are
the problem.
One could rule this out by writing a minimal alsa app which does nothing
but writing/reading from an alsa device. Make it sched_fifo, mlock its
memory, and register the alsa xrun callback [if such a thing exists, i
know very little alsa_pcm programming]. Then see if it experiences
xruns, too. If not, then jackd is probably to blame.
Also maybe the alsa drivers themselfes might be problematic/buggy. If
the above minimal alsa app still produces xruns, then either alsa lib or
the drivers themselfes are to blame [probably].
Of course such a test is not a proof but might give important clues.