17 Apr
2003
17 Apr
'03
9:39 a.m.
Hello all
I'm trying to get a gentoo based audio box (primarily Ardour) off the ground. Despite
my best efforts,
I can't eliminate xruns to a level I could live with (10ms+ xruns every 2 minutes on
average seems
excessive - esp. with stereo @ 44k1). There's some captured data at the very end of
this mail.
My observations are made using;
jackd -v -R -d... -r 44100 -p 128 2>&1 | tee jacklog (i.e. stereo SB16 @44k1)
and ardour, session open but not actively playing
I'll present my questions before wandering off into a tedious list (apologies for
length) of stuff I've
already done. Would anyone care to offer an opinion on these questions;
1. Am I expecting too much? Either from my hardware, or the current state of Linux.
2. Is there a vital piece of config that I've totally overlooked?
3. Is there a better way to measure this to home in on the source of the problem?
4. Are the xruns incidental to the disk activity - is this all a symptom of something
else?
5. Insert any other question I should be asking here.
Thanks in advance for any help/advice offered, I've run out of ideas.
Ta
R
The (abridged) story so far...
Google
Patched 2.4.20 with everything I found on Andrew Mortons page
Read http://myweb.cableone.net/eviltwin69/Arcana.html
Read LAU resource links
Fixed snd-card IRQ to 9
PCI latency timers set up
Killed cron/syslog
Switched to reiserfs (in desperation)
Tried hdparm incantations to no effect
Run bonnie (if I understand this, I'm getting 25Mb/s sustained block bandwidth)
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
2000 7467 73.6 25491 24.5 12476 8.3 10739 75.3 25217 10.8 90.8 1.2
Checked /var/log/messages for signs of IDE bus failures
Upgraded to alsa-driver 0.9.2
Re-emerged jack from CVS
Monkeyed with vm settings to try to smooth out the disk activity
The hardware:
Duron 1300MHz, Abit KT7A
512M PC133
primary IDE: Seagate ST360021A, QUANTUM FIREBALLP AS40.0 (80 way ribbon)
secondary IDE: CD/CDRW
AGP graphics card
SB16/128 PCI (i know - it's junk)
3Com PCI 3c905
0: 674864 XT-PIC timer
1: 7927 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
9: 1166 XT-PIC Ensoniq AudioPCI
11: 21381 XT-PIC eth0
12: 94912 XT-PIC PS/2 Mouse
14: 13585 XT-PIC ide0
15: 9 XT-PIC ide1
NMI: 0
LOC: 674826
ERR: 114
MIS: 0
lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Subsystem: ABIT Computer Corp. KT7/KT7-RAID/KT7A/KT7A-RAID Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort+ >SERR- <PERR-
Latency: 8
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-i
f 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: e6000000-e7ffffff
Prefetchable memory behind bridge: e4000000-e5ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40
)
Subsystem: ABIT Computer Corp.: Unknown device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master
IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. VT8235 Bus Master ATA133/100/66/33 IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 11
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 2000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at dc00 [size=64]
Expansion ROM at <unassigned> [disabled] [size=64K]
00:0d.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI128
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 248 (3000ns min, 32000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at e000 [size=64]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64
/Model 64 Pro] (rev 15) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e6000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e4000000 (32-bit, prefetchable) [size=32M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:04 init
2 ? SW 0:00 [keventd]
3 ? SWN 0:00 [ksoftirqd_CPU0]
4 ? SW 0:00 [kswapd]
5 ? SW 0:00 [bdflush]
6 ? SW 0:00 [kupdated]
7 ? SW 0:00 [kreiserfsd]
31 ? S 0:00 /sbin/devfsd /dev
1198 vc/1 S 0:00 login -- root
1199 vc/2 S 0:00 /sbin/agetty 38400 tty2 linux
1200 vc/3 S 0:00 /sbin/agetty 38400 tty3 linux
1201 vc/4 S 0:00 /sbin/agetty 38400 tty4 linux
1202 vc/5 S 0:00 /sbin/agetty 38400 tty5 linux
1203 vc/6 S 0:00 /sbin/agetty 38400 tty6 linux
1204 vc/1 S 0:00 -bash
1209 vc/1 S 0:00 /bin/sh /usr/X11R6/bin/startx
1220 vc/1 S 0:00 xinit /root/.xinitrc --
1221 ? S< 0:33 X :0
1234 vc/1 S 0:00 fvwm2
1236 vc/1 S 0:01 xterm -geometry 120x70+0+0
1239 pts/0 S 0:00 bash
1284 vc/1 S 0:00 xterm
1285 pts/1 S 0:00 bash
1288 vc/1 S 0:00 xterm
1289 pts/2 S 0:00 bash
1313 vc/1 S 0:00 xterm
1314 pts/3 S 0:00 bash
1325 pts/3 S 0:00 alsamixer
1387 vc/1 S 0:00 xterm
1388 pts/4 S 0:00 bash
1398 vc/1 S 0:00 xterm
1399 pts/5 S 0:00 bash
1580 pts/0 S 0:00 jackd -v -R -d alsa -d card0 -r 44100 -p 128
1581 pts/0 S 0:00 tee jacklog
1582 pts/0 SL 0:11 jackd -v -R -d alsa -d card0 -r 44100 -p 128
1589 pts/2 SL 0:26 /usr/lib/ardour/ardourx
1616 pts/1 S 0:00 emacs jacklog.awk
1631 pts/1 R 0:00 ps ax
I used this (jacklog.awk) to parse the output from jackd:
>>>
$0 ~/load/ {
count++;
seconds++;
}
$0 ~/xrun/ {
cost = ($7 * 1000)/count;
print count "\t" $7 * 1000 "\t" cost;
count = 0;
xruns++;
}
END {
minutes = int(seconds / 60);
seconds = seconds - (minutes * 60);
time = (minutes * 60) + seconds;
print xruns " xruns in " minutes":"seconds " (" time
" seconds) average " time/xruns;
}
<<<<
which gave me this (cost function is extremely crude);
108 675 6.25
207 690 3.33333
196 1400 7.14286
34 10608 312
69 2658 38.5217
44 14553 330.75
117 465 3.97436
39 913 23.4103
206 1724 8.36893
108 8710 80.6481
176 12596 71.5682
58 1237 21.3276
182 15688 86.1978
53 4315 81.4151
233 1100 4.72103
95 8932 94.0211
5 1917 383.4
83 6378 76.8434
44 226 5.13636
10 7923 792.3
10 825 82.5
44 6949 157.932
44 1094 24.8636
15 455 30.3333
88 1220 13.8636
25 xruns in 39:30 (2370 seconds) average 94.8
17 Apr
17 Apr
10:28 a.m.
Rob,
The basic setup of the machine looks pretty good to me. If your
eventual intention is to record audio, then you may want to consider a
second hard drive later, but I think that has nothing to do with this
problem.
If I understand your setup, then you have no 'planned' disk activity
when you are running this test? (Other than the writing of your log
file?) What happens to xruns if you start some activity in another
terminal? Say large file copies, or playing a CD?
What happens when you run with -p 256 or -p 512? Is it OK? Running
with latencies this low with a SB16 might just be beyond its
capabilities. I got xruns on my 500MHz P3 running at less than 256 using
an Audiophile 2496, but I can run my Athlon XP 2600+ at 64 with my RME
cards, so ther are limits to wht these cards can do.
Mark
On Thu, 2003-04-17 at 04:28, rob fell wrote:
Hello all
I'm trying to get a gentoo based audio box (primarily Ardour) off the ground. Despite
my best efforts,
I can't eliminate xruns to a level I could live with (10ms+ xruns every 2 minutes on
average seems
excessive - esp. with stereo @ 44k1). There's some captured data at the very end of
this mail.
My observations are made using;
jackd -v -R -d... -r 44100 -p 128 2>&1 | tee jacklog (i.e. stereo SB16 @44k1)
and ardour, session open but not actively playing
I'll present my questions before wandering off into a tedious list (apologies for
length) of stuff I've
already done. Would anyone care to offer an opinion on these questions;
1. Am I expecting too much? Either from my hardware, or the current state of Linux.
2. Is there a vital piece of config that I've totally overlooked?
3. Is there a better way to measure this to home in on the source of the problem?
4. Are the xruns incidental to the disk activity - is this all a symptom of something
else?
5. Insert any other question I should be asking here.
Thanks in advance for any help/advice offered, I've run out of ideas.
Ta
R
11:14 a.m.
I've had success with the latest gentoo-sources w/low latency turned
on. I've never bothered with ext3 / reiser. In theory, one day xfs will
be the right filesystem for multimedia, until then i'll stick with ext2
as it's stabler.
The current jack from cvs seems flakier with apps other than ardour.
If you watch in top does any process regularly spike? It's all i can
think of, unless the SB just can't take it...
j.
On Thursday, April 17, 2003, at 08:28 PM, rob fell wrote:
Hello all
I'm trying to get a gentoo based audio box (primarily Ardour) off the
ground. Despite my best efforts,
I can't eliminate xruns to a level I could live with (10ms+ xruns
every 2 minutes on average seems
excessive - esp. with stereo @ 44k1). There's some captured data at
the very end of this mail.
My observations are made using;
jackd -v -R -d... -r 44100 -p 128 2>&1 | tee jacklog (i.e. stereo SB16
@44k1)
and ardour, session open but not actively playing
I'll present my questions before wandering off into a tedious list
(apologies for length) of stuff I've
already done. Would anyone care to offer an opinion on these questions;
1. Am I expecting too much? Either from my hardware, or the current
state of Linux.
2. Is there a vital piece of config that I've totally overlooked?
3. Is there a better way to measure this to home in on the source of
the problem?
4. Are the xruns incidental to the disk activity - is this all a
symptom of something else?
5. Insert any other question I should be asking here.
Thanks in advance for any help/advice offered, I've run out of ideas.
Ta
R
The (abridged) story so far...
Google
Patched 2.4.20 with everything I found on Andrew Mortons page
Read http://myweb.cableone.net/eviltwin69/Arcana.html
Read LAU resource links
Fixed snd-card IRQ to 9
PCI latency timers set up
Killed cron/syslog
Switched to reiserfs (in desperation)
Tried hdparm incantations to no effect
Run bonnie (if I understand this, I'm getting 25Mb/s sustained block
bandwidth)
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
2000 7467 73.6 25491 24.5 12476 8.3 10739 75.3 25217 10.8
90.8 1.2
Checked /var/log/messages for signs of IDE bus failures
Upgraded to alsa-driver 0.9.2
Re-emerged jack from CVS
Monkeyed with vm settings to try to smooth out the disk activity
The hardware:
Duron 1300MHz, Abit KT7A
512M PC133
primary IDE: Seagate ST360021A, QUANTUM FIREBALLP AS40.0 (80 way
ribbon)
secondary IDE: CD/CDRW
AGP graphics card
SB16/128 PCI (i know - it's junk)
3Com PCI 3c905
0: 674864 XT-PIC timer
1: 7927 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
9: 1166 XT-PIC Ensoniq AudioPCI
11: 21381 XT-PIC eth0
12: 94912 XT-PIC PS/2 Mouse
14: 13585 XT-PIC ide0
15: 9 XT-PIC ide1
NMI: 0
LOC: 674826
ERR: 114
MIS: 0
lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
(rev 03)
Subsystem: ABIT Computer Corp. KT7/KT7-RAID/KT7A/KT7A-RAID
Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort+ >SERR-
<PERR-
Latency: 8
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133
AGP] (prog-i
f 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort+ >SERR-
<PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: e6000000-e7ffffff
Prefetchable memory behind bridge: e4000000-e5ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 40
)
Subsystem: ABIT Computer Corp.: Unknown device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort- >SERR-
<PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC
Bus Master
IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. VT8235 Bus Master
ATA133/100/66/33 IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort- >SERR-
<PERR-
Latency: 32
Region 4: I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 40)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort- >SERR-
<PERR-
Interrupt: pin ? routed to IRQ 11
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX
[Boomerang]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort- >SERR-
<PERR-
Latency: 32 (750ns min, 2000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at dc00 [size=64]
Expansion ROM at <unassigned> [disabled] [size=64K]
00:0d.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI128
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort-
<MAbort- >SERR- <PERR-
Latency: 248 (3000ns min, 32000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at e000 [size=64]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA
TNT2 Model 64
/Model 64 Pro] (rev 15) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort
- <MAbort- >SERR-
<PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e6000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at e4000000 (32-bit, prefetchable) [size=32M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:04 init
2 ? SW 0:00 [keventd]
3 ? SWN 0:00 [ksoftirqd_CPU0]
4 ? SW 0:00 [kswapd]
5 ? SW 0:00 [bdflush]
6 ? SW 0:00 [kupdated]
7 ? SW 0:00 [kreiserfsd]
31 ? S 0:00 /sbin/devfsd /dev
1198 vc/1 S 0:00 login -- root
1199 vc/2 S 0:00 /sbin/agetty 38400 tty2 linux
1200 vc/3 S 0:00 /sbin/agetty 38400 tty3 linux
1201 vc/4 S 0:00 /sbin/agetty 38400 tty4 linux
1202 vc/5 S 0:00 /sbin/agetty 38400 tty5 linux
1203 vc/6 S 0:00 /sbin/agetty 38400 tty6 linux
1204 vc/1 S 0:00 -bash
1209 vc/1 S 0:00 /bin/sh /usr/X11R6/bin/startx
1220 vc/1 S 0:00 xinit /root/.xinitrc --
1221 ? S< 0:33 X :0
1234 vc/1 S 0:00 fvwm2
1236 vc/1 S 0:01 xterm -geometry 120x70+0+0
1239 pts/0 S 0:00 bash
1284 vc/1 S 0:00 xterm
1285 pts/1 S 0:00 bash
1288 vc/1 S 0:00 xterm
1289 pts/2 S 0:00 bash
1313 vc/1 S 0:00 xterm
1314 pts/3 S 0:00 bash
1325 pts/3 S 0:00 alsamixer
1387 vc/1 S 0:00 xterm
1388 pts/4 S 0:00 bash
1398 vc/1 S 0:00 xterm
1399 pts/5 S 0:00 bash
1580 pts/0 S 0:00 jackd -v -R -d alsa -d card0 -r 44100 -p 128
1581 pts/0 S 0:00 tee jacklog
1582 pts/0 SL 0:11 jackd -v -R -d alsa -d card0 -r 44100 -p 128
1589 pts/2 SL 0:26 /usr/lib/ardour/ardourx
1616 pts/1 S 0:00 emacs jacklog.awk
1631 pts/1 R 0:00 ps ax
I used this (jacklog.awk) to parse the output from jackd:
>>>
$0 ~/load/ {
count++;
seconds++;
}
$0 ~/xrun/ {
cost = ($7 * 1000)/count;
print count "\t" $7 * 1000 "\t" cost;
count = 0;
xruns++;
}
END {
minutes = int(seconds / 60);
seconds = seconds - (minutes * 60);
time = (minutes * 60) + seconds;
print xruns " xruns in " minutes":"seconds " (" time
" seconds)
average " time/xruns;
}
<<<<
which gave me this (cost function is extremely crude);
108 675 6.25
207 690 3.33333
196 1400 7.14286
34 10608 312
69 2658 38.5217
44 14553 330.75
117 465 3.97436
39 913 23.4103
206 1724 8.36893
108 8710 80.6481
176 12596 71.5682
58 1237 21.3276
182 15688 86.1978
53 4315 81.4151
233 1100 4.72103
95 8932 94.0211
5 1917 383.4
83 6378 76.8434
44 226 5.13636
10 7923 792.3
10 825 82.5
44 6949 157.932
44 1094 24.8636
15 455 30.3333
88 1220 13.8636
25 xruns in 39:30 (2370 seconds) average 94.8
23 Apr
23 Apr
6:06 p.m.
hello Rob,
--- rob fell <robin.fell(a)ntlworld.com> wrote: > Hello all
I'm trying to get a gentoo based audio box (primarily Ardour) off
the ground. Despite my best efforts,
I can't eliminate xruns to a level I could live with (10ms+ xruns
every 2 minutes on average seems
excessive - esp. with stereo @ 44k1). There's some captured data at
the very end of this mail.
My observations are made using;
jackd -v -R -d... -r 44100 -p 128 2>&1 | tee jacklog (i.e. stereo
SB16 @44k1)
and ardour, session open but not actively playing
I'll present my questions before wandering off into a tedious list
(apologies for length) of stuff I've
already done. Would anyone care to offer an opinion on these
questions;
1. Am I expecting too much? Either from my hardware, or the current
state of Linux.
2. Is there a vital piece of config that I've totally overlooked?
3. Is there a better way to measure this to home in on the source
of the problem?
4. Are the xruns incidental to the disk activity - is this all a
symptom of something else?
5. Insert any other question I should be asking here.
Thanks in advance for any help/advice offered, I've run out of
ideas.
Ta
R
<SNIP>
The hardware:
Duron 1300MHz, Abit KT7A
512M PC133
primary IDE: Seagate ST360021A, QUANTUM FIREBALLP AS40.0 (80 way
ribbon)
secondary IDE: CD/CDRW
AGP graphics card
SB16/128 PCI (i know - it's junk)
3Com PCI 3c905
0: 674864 XT-PIC timer
1: 7927 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
9: 1166 XT-PIC Ensoniq AudioPCI
11: 21381 XT-PIC eth0
12: 94912 XT-PIC PS/2 Mouse
14: 13585 XT-PIC ide0
15: 9 XT-PIC ide1
NMI: 0
LOC: 674826
ERR: 114
MIS: 0
<SNIP>
looking at your IRQ's and the "priority list" at:
http://myweb.cableone.net/eviltwin69/Arcana.html#IRQs
i see that both your mouse (?!) and your network card seem to have
higher priority than your IDE channels (harddisks).
i would advice you to try without the network card and not to move
your mouse =)
and what Mark Knecht said about period size for the SB soundcards is
also slightly touched here: http://www.djcj.org/LAU/jack/
your 128 setting might be too small. did you try with 256 or 512?
and ofcourse... good luck.
ALEX
__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer
8:29 p.m.
Hi Alex
i see that both your mouse (?!) and your network card
seem to have
higher priority than your IDE channels (harddisks).
i would advice you to try without the network card and not to move
your mouse =)
believe it or not i did try an "ifconfig eth0 down" to see if it would improve
the situation! (i did say i was getting desperate).
and what Mark Knecht said about period size for the SB
soundcards is
also slightly touched here: http://www.djcj.org/LAU/jack/
your 128 setting might be too small. did you try with 256 or 512?
looks like no-one is using anything as cruddy as a SB128 PCI anymore (and with
good reason).
when Mark suggested that the card might not be man-enough for the job i
realised that my internal model of how a soundcard works might be a little
naive - i suspect it has more than a lump of DP ram and some counters :)
i set the buffersize smaller to try to act as a crude filter to make my awk
script simpler - though this neglects the effect on the card itself of
running at a higher rate.
the most success so far with the testing seems to be at 1024 - though large
file copies causes massive xruns at any rate (BTW: how large would a 'large'
file be?).
i can't decide whether to gamble on the purchase of a decent card and hope
this all goes away, or whether to read the alsa driver code for the card to
see if i can work out just how bad the card really is :(
and ofcourse... good luck.
looks like i may need it - and some more spare time. thanks.
R
11:14 p.m.
Yeah, you can get an sblive value oem for only $28, but could it also be
an old disk or something? Also it could be your video card, I had that
problem with an ati rage card that was causing horrible x runs
http://www.brianredfern.org
On Wed, 23 Apr 2003, rob fell wrote:
Hi Alex
i see that both your mouse (?!) and your network
card seem to have
higher priority than your IDE channels (harddisks).
i would advice you to try without the network card and not to move
your mouse =)
believe it or not i did try an "ifconfig eth0 down" to see if it would improve
the situation! (i did say i was getting desperate).
and what Mark Knecht said about period size for
the SB soundcards is
also slightly touched here: http://www.djcj.org/LAU/jack/
your 128 setting might be too small. did you try with 256 or 512?
looks like no-one is using anything as cruddy as a SB128 PCI anymore (and with
good reason).
when Mark suggested that the card might not be man-enough for the job i
realised that my internal model of how a soundcard works might be a little
naive - i suspect it has more than a lump of DP ram and some counters :)
i set the buffersize smaller to try to act as a crude filter to make my awk
script simpler - though this neglects the effect on the card itself of
running at a higher rate.
the most success so far with the testing seems to be at 1024 - though large
file copies causes massive xruns at any rate (BTW: how large would a 'large'
file be?).
i can't decide whether to gamble on the purchase of a decent card and hope
this all goes away, or whether to read the alsa driver code for the card to
see if i can work out just how bad the card really is :(
and ofcourse... good luck.
looks like i may need it - and some more spare time. thanks.
R
11:58 p.m.
On Wed, 23 Apr 2003, rob fell wrote:
> Hi Alex
>
> > i see that both your mouse (?!) and your network card seem to have
> > higher priority than your IDE channels (harddisks).
> > i would advice you to try without the network card and not to move
> > your mouse =)
Normally there isn't much you can do about this, other than put in some
other ATA disk controller or go SCSI, which I wouldn't recommend just
yet. Fortunately I don't think any of that is really necessary just yet.
These are good experiments though. On the NIC side, just unpluging the
cable would normally be enough to test.
>
> when Mark suggested that the card might not be man-enough for the job i
> realised that my internal model of how a soundcard works might be a little
> naive - i suspect it has more than a lump of DP ram and some counters :)
This is where I think we really start getting into PC chipset design.
(something I used to do for AMD.) Without belaboring the details, a good
card is capable of getting data to and from memory without much
processor interaction and very efficiently on the PCI bus. If it does
that, then what's left is basically how it tells the processor what's
going on, which is the interrupt service routine's job. However, even a
great sound card can be hindered by other parts of the PC (like other
PCI cards) usign the bus badly.
You don't happen to be using a PCI VGA adapter, do you? I Cannot
remember at this point.
>
> i set the buffersize smaller to try to act as a crude filter to make my awk
> script simpler - though this neglects the effect on the card itself of
> running at a higher rate.
>
> the most success so far with the testing seems to be at 1024 - though large
> file copies causes massive xruns at any rate (BTW: how large would a 'large'
> file be?).
This sounds like an interrupt problem, or else a bad set of hard disk
device drivers. If you sound card want to interrupt, it should get
serviced even if the hard disk was on the bus. Possibly the DMA
controller in this ATA chipset isn't very efficient....
>
> i can't decide whether to gamble on the purchase of a decent card and hope
> this all goes away, or whether to read the alsa driver code for the card to
> see if i can work out just how bad the card really is :(
I think I'd maybe try running Benno's disk latency test first. IF it
says you have long latency issues in your disk subsystem, then a newer
sound card isn't going to do you much good.
and ofcourse... good luck.
looks like i may need it - and some more spare time. thanks.
26 Apr
26 Apr
7:24 a.m.
Hi Mark
this is sounding expensive...
surely others in the LL audio world are using the "IDE interface: VIA
Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06)" - has
anyone anything good/bad to say about this (BTW: i did enable all the 'fix
borken VIA' stuff in the kernel options).
Normally there isn't much you can do about this,
other than put in some
other ATA disk controller or go SCSI, which I wouldn't recommend just
yet. Fortunately I don't think any of that is really necessary just yet.
These are good experiments though. On the NIC side, just unpluging the
cable would normally be enough to test.
well - i didn't unplug the cable, but i did an ifconfig eth0 down, which AFAIK
closes the interface entirely. i'm behind a firewall too, so i shouldn't be
exposed to the usual babble of ill-config'd M$ machines.
i'm willing to be disabused by someone knowledgeable here.
This is where I think we really start getting into PC
chipset design.
(something I used to do for AMD.) Without belaboring the details, a good
card is capable of getting data to and from memory without much
processor interaction and very efficiently on the PCI bus. If it does
that, then what's left is basically how it tells the processor what's
going on, which is the interrupt service routine's job. However, even a
great sound card can be hindered by other parts of the PC (like other
PCI cards) usign the bus badly.
You don't happen to be using a PCI VGA adapter, do you? I Cannot
remember at this point.
i wish it were so easy - i have AGP.
> the most
success so far with the testing seems to be at 1024 - though
> large file copies causes massive xruns at any rate (BTW: how large
> would a 'large' file be?).
This sounds like an interrupt problem, or else a bad set of hard disk
device drivers. If you sound card want to interrupt, it should get
serviced even if the hard disk was on the bus. Possibly the DMA
controller in this ATA chipset isn't very efficient.... I think I'd maybe try running Benno's disk
latency test first. IF it
says you have long latency issues in your disk subsystem, then a newer
sound card isn't going to do you much good.
it segfaults for me. it inspired me to try to use the jackd output as a guide
for tuning the machine since i realised i wouldn't get far without some sort
of measurement/instrumentation.
so my current alternatives are;
1. post my results
2. learn gdb and try to get latency test to work
3. buy a new snd card. pray.
4. buy a PCI IDE card. waste a lot of time. pray.
5. buy a new mobo whose chipset is recommended.
i'll post again when i've organised my test results. hopefully someone smarter
than i can make some sense of it all (well audio-wise anyhow) and point me in
the right direction.....
thanks all for your assistance thus far
R
12:56 p.m.
rob fell <robin.fell(a)ntlworld.com> writes:
I haven't been following this thread closely. So, pardon me if I'm
going over old ground. My ASUS A7V333 mobo has a similar IDE
controller...
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a
[Master SecP PriP])
Subsystem: Asustek Computer, Inc.: Unknown device 808c
Flags: bus master, medium devsel, latency 32
I/O ports at a000 [size=16]
Capabilities: [c0] Power Management version 2
It's works well at fairly low latencies. But, to get that working, I
had to upgrade my kernel to 2.4.19. The 2.4.18 (and earlier) IDE
device driver unable to do DMA with this chip. Fixing that made a
dramatic improvement in disk performance.
Have you already gone through all the hdparms rigamarole?
--
Jack O'Quin
Austin, Texas, USA
This sounds
like an interrupt problem, or else a bad set of hard disk
device drivers. If you sound card want to interrupt, it should get
serviced even if the hard disk was on the bus. Possibly the DMA
controller in this ATA chipset isn't very efficient....
this is sounding expensive...
surely others in the LL audio world are using the "IDE interface: VIA
Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06)" - has
anyone anything good/bad to say about this (BTW: i did enable all the 'fix
borken VIA' stuff in the kernel options).
30 Apr
30 Apr
6:21 p.m.
I haven't been following this thread closely. So,
pardon me if I'm
going over old ground. My ASUS A7V333 mobo has a similar IDE
controller...
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP]) Subsystem: Asustek Computer, Inc.: Unknown
device 808c
Flags: bus master, medium devsel, latency 32
I/O ports at a000 [size=16]
Capabilities: [c0] Power Management version 2
It's works well at fairly low latencies. But, to get that working, I
had to upgrade my kernel to 2.4.19. The 2.4.18 (and earlier) IDE
device driver unable to do DMA with this chip. Fixing that made a
dramatic improvement in disk performance.
Have you already gone through all the hdparms rigamarole?
Thanks for the tips. I have been through the whole hdparm/setpci thing, all to
no avail.
Luckily, Mark Knecht's mail reminded me that I had never got the latency test
program working - so I persevered, and got results (which can be found here
http://homepage.ntlworld.com/robin.fell/ ).
If I understand the output (and Mark's email) correctly I probably do have a
lousy soundcard, though I don't really understand how the program guarantees
to measure my latency woes - so I'm a little reticent to shell out 300 notes
for the terratec I desire.
Being ignorant of the API's used to send sound to the card during it's
measurements, I don't see how it can tell me anything about how well the IDE
controller is playing with the soundcard on the PCI bus. Can anyone explain
it to me?
Thanks all for your help.
R
7:06 p.m.
Thanks for the tips. I have been through the whole hdparm/setpci
thing, all to
no avail.
Luckily, Mark Knecht's mail reminded me that I had never got the
latency test
program working - so I persevered, and got results (which can be
found here
http://homepage.ntlworld.com/robin.fell/ ).
If I understand the output (and Mark's email) correctly I
probably do have a
lousy soundcard, though I don't really understand how the program
guarantees
to measure my latency woes - so I'm a little reticent to shell
out 300 notes
for the terratec I desire.
Being ignorant of the API's used to send sound to the card during it's
measurements, I don't see how it can tell me anything about how
well the IDE
controller is playing with the soundcard on the PCI bus. Can
anyone explain
it to me?
Thanks all for your help.
R
Rob,
Looks like you're making a lot of headway. I am struck by how different
your tests and my tests look. Mine are captured on Jan Depner's
configuration pages. The correct page is here:
http://myweb.cableone.net/eviltwin69/Arcana.html#Mark%20Knecht's%20file…
m%20tests
Go down to section 2.6 and then to the links, like the one for my ext3
tests:
http://myweb.cableone.net/eviltwin69/Latency_Graphs/ext3_html/3x256.html
Note that my white band (the latency of the disk + CPU) is very tight, while
yours is huge. Very strange.
To understand this plot (at least the way I understand the plot!) the green
line is the amount of time the CPU takes to execute the test when you don't
go to disk. The white is CPU + disk, so that you can see the contributions
of each.
While yours is quite different than mine, still you're disk latencies are
below about 2.1mS. (See info at bottom of each graph.) This means, on paper
anyway, that the disk sub system could run with 3mS latencies from the audio
buffers and you should not have a problem.
However, if I remember your problems, you are getting an xrun every 30
minutes or so. Therefore the chances of you seeing that failure while
running this test is pretty low, assuming it is coming from your disks and
not from something else.
Bottom line, I think the disks are operating OK. Whether a new card is
really going to fix this is another issue.
I had a system here in the office with a SB Audigy in it. I got one xrun, on
the average, about every hour. I turned of crond and they went away
completely. I cannot blame that on the Audigy. I think it was just Linux...
Cheers,
Mark
7:46 p.m.
On Wed, Apr 30, 2003 at 09:04:18PM +0100, rob fell wrote:
Luckily, Mark Knecht's mail reminded me that I had
never got the latency test
program working - so I persevered, and got results (which can be found here
http://homepage.ntlworld.com/robin.fell/ ).
If I understand the output (and Mark's email) correctly I probably do have a
lousy soundcard,
to me it looks like those results are really good.
you got no overruns at all.
what we really need is to get latencytest to be a jack client so we
can see if jack makes latency worse. it should not, but some people
have reported that it does. i haven't seen any real data.
--
Paul Winkler
home: http://www.slinkp.com
"Muppet Labs, where the future is made - today!"
24 Apr
24 Apr
10:13 p.m.
Hi
I had a similar experience with my setup (athlon_xp, redhat 8 planetccrma, sblive
emu10k1)
changing the old IDE cables for brand new ATA133, fixed it!.
just my personal experience.
cheers,
cables.
On Wed, 23 Apr 2003, rob fell wrote:
Hi Alex
i see that both your mouse (?!) and your network
card seem to have
higher priority than your IDE channels (harddisks).
i would advice you to try without the network card and not to move
your mouse =)
believe it or not i did try an "ifconfig eth0 down" to see if it would improve
the situation! (i did say i was getting desperate).
and what Mark Knecht said about period size for
the SB soundcards is
also slightly touched here: http://www.djcj.org/LAU/jack/
your 128 setting might be too small. did you try with 256 or 512?
looks like no-one is using anything as cruddy as a SB128 PCI anymore (and with
good reason).
when Mark suggested that the card might not be man-enough for the job i
realised that my internal model of how a soundcard works might be a little
naive - i suspect it has more than a lump of DP ram and some counters :)
i set the buffersize smaller to try to act as a crude filter to make my awk
script simpler - though this neglects the effect on the card itself of
running at a higher rate.
the most success so far with the testing seems to be at 1024 - though large
file copies causes massive xruns at any rate (BTW: how large would a 'large'
file be?).
i can't decide whether to gamble on the purchase of a decent card and hope
this all goes away, or whether to read the alsa driver code for the card to
see if i can work out just how bad the card really is :(
and ofcourse... good luck.
looks like i may need it - and some more spare time. thanks.
R
7872
days inactive
7885
days old
linux-audio-user@lists.linuxaudio.org
12 comments
9 participants
participants (9)
-
Alex Timmer -
Brian Redfern -
Francisco Oltra -
Jack O'Quin -
Jon Ellis -
Mark Knecht -
Mark Knecht -
Paul Winkler -
rob fell