2 Oct
2004
2 Oct
'04
7:16 p.m.
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.
How would we debug this further? I am stumped...
-----Forwarded Message-----
From: John Hedditch <jhedditc(a)physics.adelaide.edu.au>
To: Lee Revell <rlrevell(a)joe-job.com>
Subject: Re: Linux audio latency
Date: Sun, 03 Oct 2004 05:39:17 +0930
Actually, it's looking good. I can cheesetracker plus a few different
hydrogens running at the same time with no xruns if I go to -p256.
Still, it's a bit sad that this takes us over the magical 3ms ...
No xruns with no clients. Hmmmm. OK. I now know how to kill it completely.
ardour + 3 parallel find *'s + freqtweak = 100s of xruns, and the
following latency trace
preemption latency trace v1.0.7 on 2.6.9-rc2-mm4-VP-S7
-------------------------------------------------------
latency: 206 us, entries: 2 (2) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
-----------------
| task: ksoftirqd/0/2, uid:0 nice:-10 policy:0 rt_prio:0
-----------------
=> started at: rtl8139_poll+0x3c/0x10e
=> ended at: rtl8139_rx+0x22b/0x347
=======>
00000001 0.000ms (+0.206ms): rtl8139_poll (net_rx_action)
00000001 0.206ms (+0.000ms): touch_preempt_timing (rtl8139_rx)
On Sat, Oct 02, 2004 at 04:18:41PM -0400, Lee Revell wrote:
On Sat, 2004-10-02 at 15:54, John Hedditch wrote:
Still xruns. That is with the following settings:
usr/bin/jackd -R -p512 -t200 -dalsa -dhw:0 -r96000 -p128 -n2 -M
Hmm, ok. I did not realize you were running at 96KHZ. Still, it does
not look like a kernel issue. Do the xruns correspond to any particular
system activity? Do you get xruns if you run jackd with no clients and
load the system heavily?
Lee 
2 Oct
2 Oct
7:33 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] [Fwd: Re: Linux audio latency]
On Sat, 02 Oct 2004 16:58:57 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
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.
flo
8:12 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] [Fwd: Re: Linux audio latency]
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.
7387
days inactive
7387
days old
linux-audio-user@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Florian Schmidt -
Lee Revell