28 Sep
2004
28 Sep
'04
4:16 a.m.
I just tonight switched from the Planet CCRMA RH9 to FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
28 Sep
28 Sep
4:58 a.m.
On Monday 27 September 2004 10:59 pm, brad stafford wrote:
I just tonight switched from the Planet CCRMA RH9 to
FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
To semi paraphrase something I think Mr. Knecht conveyed nicely earlier, and I
also believe with much merit...and in my own short but sweet format...
Unless your box has plumes of dark grey smoke billowing from it because of the
Xruns overload {Well, Athalon does run hot....it could happen} or...
The sound is so choppy, it sounds like an extratarestrial life form is trying
to contact you or...
you just ~can't~ sleep at night bareing the thought of a single Xrun passing
b4 your eyes...
And assuming your sound is clean and glitchless...I gotta say...If you are
getting 5.8 msec @ 128x2 with clean sound and a stable, happy jack...other
than those pesky lil' "0 (0)" buggers in the Qjackctl window turnng red on
you...Just BACK AWAY FROM THE INTERRUPTS MR.!!!....Put those pci cards down
nice and slow and get them hands up where we can see 'em! Put the cover BACK
on the machine and record 3 verses of "Don't worry, Be happy"!
I am also using a Delta 1010LT on an Athalon Barton chip with a tad less than
1gig DDR 2700 ram. I screwed with it endlessly seeking that "super setup"
you know...the setup so clean the bugger will compose, record and mix the
music all by itself...And I wasted LOTS of damn time I could have spent doing
what WE ACTUALLY are meant to do this for...CREATE MUZIC! :)
I run the 2.6 kernel with Realtime-lsm as my only real latency improvement
patch {and whatever other bits 'n' pieces Thac's sticks in his kernels} I
have been recording in Ardour at 256x2. If the dang Xruns start to give me
the urge to break a perfectly good working DAW, I put the SOB in "soft
mode"! :) No mo' Xruns! And the recording, even running plugins whilst
recording, is perfectly acceptable.
The point I'm trying to make is...apply some attention to tweaking your box
but not to the point of distraction. If it's working well, I don't care if my
soundcard is on INT 204! {eh hem} :)
Happy recording and music making!!
R~
--
The Road of Life is paved with Squirrels that couldn't make a decision!
1:05 p.m.
Thanks Mark and Russell for the reply. I'll be happy with what I have and
stop trying to get latency into the negative range (if something happens in
the forest before it happens did it really happen?)
I'll go make music now... I'm one happy tweak-head!
Brad.
----- Original Message -----
From: "Russell Hanaghan" <hanaghan(a)starband.net>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Tuesday, September 28, 2004 1:42 AM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
On Monday 27 September 2004 10:59 pm, brad stafford
wrote:
and I
I just tonight switched from the Planet CCRMA RH9
to FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
To semi paraphrase something I think Mr. Knecht conveyed nicely earlier, also believe with much merit...and in my own short but
sweet format...
Unless your box has plumes of dark grey smoke billowing from it because of
the
Xruns overload {Well, Athalon does run hot....it could
happen} or...
The sound is so choppy, it sounds like an extratarestrial life form is
trying
to contact you or...
you just ~can't~ sleep at night bareing the thought of a single Xrun
passing
b4 your eyes...
And assuming your sound is clean and glitchless...I gotta say...If you are
getting 5.8 msec @ 128x2 with clean sound and a stable, happy jack...other
than those pesky lil' "0 (0)" buggers in the Qjackctl window turnng red on
you...Just BACK AWAY FROM THE INTERRUPTS MR.!!!....Put those pci cards
down
nice and slow and get them hands up where we can see
'em! Put the cover
BACK
on the machine and record 3 verses of "Don't
worry, Be happy"!
I am also using a Delta 1010LT on an Athalon Barton chip with a tad less
than
1gig DDR 2700 ram. I screwed with it endlessly seeking
that "super setup"
you know...the setup so clean the bugger will compose, record and mix the
music all by itself...And I wasted LOTS of damn time I could have spent
doing
what WE ACTUALLY are meant to do this for...CREATE
MUZIC! :)
I run the 2.6 kernel with Realtime-lsm as my only real latency improvement
patch {and whatever other bits 'n' pieces Thac's sticks in his kernels} I
have been recording in Ardour at 256x2. If the dang Xruns start to give me
the urge to break a perfectly good working DAW, I put the SOB in "soft
mode"! :) No mo' Xruns! And the recording, even running plugins whilst
recording, is perfectly acceptable.
The point I'm trying to make is...apply some attention to tweaking your
box
but not to the point of distraction. If it's
working well, I don't care if
my
soundcard is on INT 204! {eh hem} :)
Happy recording and music making!!
R~
--
The Road of Life is paved with Squirrels that couldn't make a decision!
1:57 p.m.
Hi Brad,
I'm confused. jackstart -R -p512 -dalsa -dhw:0 -r44100
-p128 -n2 is 5.8 msec of latency and it can't be
anything else. The issue is whether or not the system
will perform reliably with these settings.
I was misinterpreting your statements. You couldn't
reliably run 128 frames with with RH9 and 2.4 kernel.
Is that correct? Doh, I went and deleted the rest of
your message--the improved low buffer size reliability
is in a FC2/2.6 kernel?
Have you done any tests with Ardour and JAMin at 128
frames?
Well, those are encouraging improvements.
With my setup, I'm getting decent enough reliability
at 128 frames but when I record and mix, I turn it
back to 1024. Under no circumstances can I tolerate a
single xrun.
ron
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
> I'm
getting 5.8 msec latency in JACK with 128
frames/period at 44100 and
> 2 periods/buffer. A huge improvement over
the
46.1 msec using RH9 with
> > capabilities. 
5:27 p.m.
On Tue, 2004-09-28 at 11:40, R Parker wrote:
With my setup, I'm getting decent enough
reliability
at 128 frames but when I record and mix, I turn it
back to 1024. Under no circumstances can I tolerate a
single xrun.
If you cannot tolerate a single xrun, then you NEED to use a low latency
kernel. Screwing around with interrupts and the FC2 kernel is a waste
of time. I get no xruns at 32 (!) frames using 2.6 with the VP patches,
and my soundcard shares an interrupt with USB:
rlrevell@mindpipe:~$ cat /proc/interrupts
CPU0
0: 65522406 XT-PIC timer 0/22406
1: 17900 XT-PIC i8042 2/17900
2: 0 XT-PIC cascade 0/0
8: 10844340 XT-PIC rtc 0/44340
10: 191142 XT-PIC uhci_hcd, EMU10K1 0/91142
11: 2875535 XT-PIC uhci_hcd, eth0 0/75535
12: 0 XT-PIC uhci_hcd 0/0
15: 163810 XT-PIC ide1 0/63809
NMI: 0
ERR: 0
rlrevell@mindpipe:~$ uname -r
2.6.9-rc2-mm3-VP-S6
Lee
6:28 p.m.
Lee Revell wrote:
If you cannot tolerate a single xrun, then you NEED to use a low latency
kernel. Screwing around with interrupts and the FC2 kernel is a waste
of time.
I agree.
I get no xruns at 32 (!) frames using 2.6 with the VP
patches,
and my soundcard shares an interrupt with USB:
(Non-argumentive if it's unclear) Please stick a USB mouse on the USB
port that is shared and wiggle it madly while doing some of this. Can
you create an xrun?
BTW - PIC or APIC interrupts?
Thanks,
Mark
7:52 p.m.
On Tue, 2004-09-28 at 16:11, Mark Knecht wrote:
Lee Revell wrote:
No, this does not cause an xrun, because even though the USB interrupt
handler interrupts the soundcard irq (and vice versa), it does not run
for a significant fraction of the period time. Of course it's best to
have the soundcard on an interrupt that is not shared. But whether that
interrupt is #5 or #10 does not matter.
I get no xruns at 32 (!) frames using 2.6 with
the VP patches,
and my soundcard shares an interrupt with USB:
(Non-argumentive if it's unclear) Please stick a USB mouse on the USB
port that is shared and wiggle it madly while doing some of this. Can
you create an xrun?
BTW - PIC or APIC interrupts?
PIC (as in I only have irqs 0-15), but APIC works the same way.
Lee
8:23 p.m.
Lee Revell wrote:
Sure. I've worked on chipset design an have a bit of background there.
Never did the PIC, but it was part of the project.
On Tue, 2004-09-28 at 16:11, Mark Knecht wrote:
Great. Just checking. (You did *actually* do it, right?) ;-) On my
Gentoo kernels, if wiggle the mouse enough I can get an xrun or two.
Normal mouse usage doesn't, but then again we're talking about a single
xrun blowing a record which we don't want.
Under Windows XP, using Pro Tools on the same laptop, I can create many
'xrun' equivalents by moving the mouse at the wrong time, so I'm very
sinsitive to it.
Shared interrupts are only slightly worse than not shared. With shared
both devices have to be interrogated even if only one generated the
interrupt. this has to take longer. However, with good IRQ ahndler code
it should not be an issue. I think the Linux environment with open
source/peer review is far more likely to weed the problems out than the
closed source Windows world.
Lee Revell wrote:
No, this does not cause an xrun, because even though the USB interrupt
handler interrupts the soundcard irq (and vice versa), it does not run
for a significant fraction of the period time. Of course it's best to
have the soundcard on an interrupt that is not shared. But whether that
interrupt is #5 or #10 does not matter. I get no xruns at 32 (!) frames using 2.6 with the
VP patches,
and my soundcard shares an interrupt with USB:
(Non-argumentive if it's unclear) Please stick a USB mouse on the USB
port that is shared and wiggle it madly while doing some of this. Can
you create an xrun?
BTW - PIC or APIC interrupts?
PIC (as in I only have irqs 0-15), but APIC works the same way.
Lee
10:22 p.m.
On Tue, 2004-09-28 at 18:05, Mark Knecht wrote:
Lee Revell wrote:
Under Windows XP, using Pro Tools on the same laptop, I can create many
'xrun' equivalents by moving the mouse at the wrong time, so I'm very
sinsitive to it.
XP is just not designed for low latency. I would not expect OS X to
have the same problem.
Shared interrupts are only slightly worse than not
shared. With shared
both devices have to be interrogated even if only one generated the
interrupt. this has to take longer. However, with good IRQ ahndler code
it should not be an issue.
Correct. I have measured the delay, is it a matter of a few
nanoseconds. Way too small to be an issue _if_ the irq handling system
is properly designed for low latency, as is the case with OSX and Linux
2.6 with the VP patches. The 2.4 low latency kernel is more of a hack.
I have also measured the delay when the USB irq handler is shared with
the sound card. With Ingo's latency tracer you can see the actual flow
of control when the USB irq interrupts the soundcard irq. It's very
small, something like 50-100 usecs. To keep this in perspective when
using jack at 32 frames, 48KHZ, you have 333 usecs to respond to the
interrupt.
Lee
11:09 p.m.
On Tue, 2004-09-28 at 17:05, Lee Revell wrote:
Correct. I have measured the delay, is it a matter of
a few
nanoseconds.
I don't mean to be argumentative but it cannot be. A single PCI clock
cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to
ensure access to the bus (removing PCI grant and waiting until all
devices are off, then sending a PCI address, getting a target hit
response and starting the read. At that point you can read a single
register, or possibly multiple registers if the chip supports it. This
is not a few nanosecond. A few micro seconds to read a single Interrutp
register in a PCI chip to see if it's involved, but not nanoseconds.
Most North Bridges cannot access the PCI bus for fewer than about 15
clocks by the time you look at their bus operations. We do this stuff
all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express
maybe, but not PCI.
If you're talking about the speed reading the PCI itself, then I'd buy
that this is much shorter as it's in the chipset. However, the processor
still has to cross the front side bus. There are latencies that arise
there dependign on what the processoris doing physically. Certainly this
time is much shorter though.
Way too small to be an issue _if_ the irq handling
system
is properly designed for low latency, as is the case with OSX and Linux
2.6 with the VP patches. The 2.4 low latency kernel is more of a hack.
I'm not a programmer. I couldn't comment on that.
I have also measured the delay when the USB irq handler is shared with
the sound card. With Ingo's latency tracer you can see the actual flow
of control when the USB irq interrupts the soundcard irq. It's very
small, something like 50-100 usecs. To keep this in perspective when
using jack at 32 frames, 48KHZ, you have 333 usecs to respond to the
interrupt.
These numbers are much more believable to me.
Lee
11:28 p.m.
On Tue, 2004-09-28 at 20:52, Mark Knecht wrote:
On Tue, 2004-09-28 at 17:05, Lee Revell wrote:
Oops, sorry, I meant microseconds. I was actually looking at a trace
when I wrote this, and Ingo's tracer prints milliseconds, and I screwed
up the conversion. It looks like 2-3 usecs to determine where the
interrupt came from if two devices share an irq.
Lee
Correct. I have measured the delay, is it a
matter of a few
nanoseconds.
I don't mean to be argumentative but it cannot be. A single PCI clock
cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to
ensure access to the bus (removing PCI grant and waiting until all
devices are off, then sending a PCI address, getting a target hit
response and starting the read. At that point you can read a single
register, or possibly multiple registers if the chip supports it. This
is not a few nanosecond. A few micro seconds to read a single Interrutp
register in a PCI chip to see if it's involved, but not nanoseconds.
Most North Bridges cannot access the PCI bus for fewer than about 15
clocks by the time you look at their bus operations. We do this stuff
all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express
maybe, but not PCI.
If you're talking about the speed reading the PCI itself, then I'd buy
that this is much shorter as it's in the chipset. However, the processor
still has to cross the front side bus. There are latencies that arise
there dependign on what the processoris doing physically. Certainly this
time is much shorter though.
29 Sep
29 Sep
12:12 p.m.
Lee Revell wrote:
On Tue, 2004-09-28 at 20:52, Mark Knecht wrote:
Thanks Lee. That's very compatible with my back-of-the-envelope
calculations. However, I believe that number assumes that the leading
interrupt device is not interrupting and you only had to determine that
the real interrupt came from the sound card. Assuming a shared
interrupt, and assuming that a USB controller is the first and the sound
card is the second device, what delay is encountered by the sound card
when both devices interrupt at the same time?
I understand that there is probably a few microseconds extra delay as
the system determines that there are two interrupt devices pending. How
long is it, however, before the UCB interrupt handler does all it's work
and hands off to the sound card interrupt handler (or sound card driver)
so that it can get started?
I grant you that this will should not amount to 500uS worth of delay,
but then we need to add in the possibilities of other, higher priority
interrupts coming along during that window and further delaying the
sound card getting it's work don before the Jack frame runs out.
For me this is not a mere curiosity. Yesterday I brought up FC2 and
then, with much help from Steve Harris and Fernando, got a new Planet
kernel installed. No sooner than I had started Jack I then started using
my USB mouse and getting huge xruns. Since USB is shared with the sound
chip I think it's an example of what we ae talking about here.
to be clear I do not think the results are completely valid as the
machine has not yet been optimized, it's running KDE, arts is trying to
start at odd times, etc., but clearly there was a relationship between
my mouse and my xruns.
(Some xruns were on the order of 100-500mS!! This cannot be truly
real...I hope)
Thanks much,
Mark
On Tue, 2004-09-28 at 17:05, Lee Revell wrote:
Oops, sorry, I meant microseconds. I was actually looking at a trace
when I wrote this, and Ingo's tracer prints milliseconds, and I screwed
up the conversion. It looks like 2-3 usecs to determine where the
interrupt came from if two devices share an irq.
Lee
Correct. I have measured the delay, is it a
matter of a few
nanoseconds.
I don't mean to be argumentative but it cannot be. A single PCI clock
cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to
ensure access to the bus (removing PCI grant and waiting until all
devices are off, then sending a PCI address, getting a target hit
response and starting the read. At that point you can read a single
register, or possibly multiple registers if the chip supports it. This
is not a few nanosecond. A few micro seconds to read a single Interrutp
register in a PCI chip to see if it's involved, but not nanoseconds.
Most North Bridges cannot access the PCI bus for fewer than about 15
clocks by the time you look at their bus operations. We do this stuff
all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express
maybe, but not PCI.
If you're talking about the speed reading the PCI itself, then I'd buy
that this is much shorter as it's in the chipset. However, the processor
still has to cross the front side bus. There are latencies that arise
there dependign on what the processoris doing physically. Certainly this
time is much shorter though.
12:45 p.m.
Since I gave such a glowing review of my testing the other night that I
thought I'd report back my not so stellar results from last night.
I left all the services running on a fully loaded machine (http, iptables,
sendmail, samba, etc...) and started jack at 128/44100/2 in real time. I
started a 20 minute recording session with ardour (no jamin yet). While
ardour was recording I dialed into the internet with my modem, opened
evolution, read email and poked around a bit with konqueror. I got zero,
nada, nil, none, no xruns whatsoever.
Then I introduced jamin - 4 xruns in 8 mins.
Shut down jamin and go back to only ardour - more xruns.
Shut down all but essential services and only use ardour - more xruns.
Seems that a bottle of xruns was opened and I can't put the cap back on.
I then changed jack settings to 256/44100/2 and the xruns went away while
only using ardour.
Back to tweaking.....
Anyone know of a twelve step program for a tweak-a-holic?
Brad
----- Original Message -----
From: "Mark Knecht" <mknecht(a)controlnet.com>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Wednesday, September 29, 2004 8:55 AM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
Lee Revell wrote:
On Tue, 2004-09-28 at 20:52, Mark Knecht wrote:
Thanks Lee. That's very compatible with my back-of-the-envelope
calculations. However, I believe that number assumes that the leading
interrupt device is not interrupting and you only had to determine that
the real interrupt came from the sound card. Assuming a shared
interrupt, and assuming that a USB controller is the first and the sound
card is the second device, what delay is encountered by the sound card
when both devices interrupt at the same time?
I understand that there is probably a few microseconds extra delay as
the system determines that there are two interrupt devices pending. How
long is it, however, before the UCB interrupt handler does all it's work
and hands off to the sound card interrupt handler (or sound card driver)
so that it can get started?
I grant you that this will should not amount to 500uS worth of delay,
but then we need to add in the possibilities of other, higher priority
interrupts coming along during that window and further delaying the
sound card getting it's work don before the Jack frame runs out.
For me this is not a mere curiosity. Yesterday I brought up FC2 and
then, with much help from Steve Harris and Fernando, got a new Planet
kernel installed. No sooner than I had started Jack I then started using
my USB mouse and getting huge xruns. Since USB is shared with the sound
chip I think it's an example of what we ae talking about here.
to be clear I do not think the results are completely valid as the
machine has not yet been optimized, it's running KDE, arts is trying to
start at odd times, etc., but clearly there was a relationship between
my mouse and my xruns.
(Some xruns were on the order of 100-500mS!! This cannot be truly
real...I hope)
Thanks much,
Mark On Tue, 2004-09-28 at 17:05, Lee Revell wrote:
Oops, sorry, I meant microseconds. I was actually looking at a trace
when I wrote this, and Ingo's tracer prints milliseconds, and I screwed
up the conversion. It looks like 2-3 usecs to determine where the
interrupt came from if two devices share an irq.
Lee
Correct. I have measured the delay, is it a
matter of a few
nanoseconds.
I don't mean to be argumentative but it cannot be. A single PCI clock
cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to
ensure access to the bus (removing PCI grant and waiting until all
devices are off, then sending a PCI address, getting a target hit
response and starting the read. At that point you can read a single
register, or possibly multiple registers if the chip supports it. This
is not a few nanosecond. A few micro seconds to read a single Interrutp
register in a PCI chip to see if it's involved, but not nanoseconds.
Most North Bridges cannot access the PCI bus for fewer than about 15
clocks by the time you look at their bus operations. We do this stuff
all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express
maybe, but not PCI.
If you're talking about the speed reading the PCI itself, then I'd buy
that this is much shorter as it's in the chipset. However, the processor
still has to cross the front side bus. There are latencies that arise
there dependign on what the processoris doing physically. Certainly this
time is much shorter though. 
12:58 p.m.
On Wed, 29 Sep 2004 09:28:17 -0500
"Brad Stafford" <brad(a)archone.tamu.edu> wrote:
Then I introduced jamin - 4 xruns in 8 mins.
Shut down jamin and go back to only ardour - more xruns.
Shut down all but essential services and only use ardour - more xruns.
Seems that a bottle of xruns was opened and I can't put the cap back on.
I then changed jack settings to 256/44100/2 and the xruns went away while
only using ardour.
Brad, I'm curious: did you stop and start JACK after you closed out
JAMin and/or Ardour? I did a session over the weekend where I had a
problem with Ardour, and would have to exit. If I didn't restart JACK
as well, I ran into issues. (I wish I could be clearer on this, but I
left my notes at home regarding this.)
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
1:27 p.m.
Interesting point Joe - no, I left jamin up and running. I'll give that a
try tonight. I'm also going to try Bill's suggestion to eliminate APCI.
Thanks, Brad.
----- Original Message -----
From: "Joe Hartley" <jh(a)brainiac.com>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Wednesday, September 29, 2004 9:41 AM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
On Wed, 29 Sep 2004 09:28:17 -0500
"Brad Stafford" <brad(a)archone.tamu.edu> wrote:
> Then I introduced jamin - 4 xruns in 8 mins.
>
> Shut down jamin and go back to only ardour - more xruns.
>
> Shut down all but essential services and only use ardour - more xruns.
>
> Seems that a bottle of xruns was opened and I can't put the cap back on.
>
> I then changed jack settings to 256/44100/2 and the xruns went away
while
only using
ardour.
Brad, I'm curious: did you stop and start JACK after you closed out
JAMin and/or Ardour? I did a session over the weekend where I had a
problem with Ardour, and would have to exit. If I didn't restart JACK
as well, I ran into issues. (I wish I could be clearer on this, but I
left my notes at home regarding this.)
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
5:13 p.m.
--- Joe Hartley <jh(a)brainiac.com> wrote:
On Wed, 29 Sep 2004 09:28:17 -0500
"Brad Stafford" <brad(a)archone.tamu.edu> wrote:
I see the same general behaviour that I think both of
you are describing; once an xrun occurs the bottle is
open and jackd must be restarted to stabilize the
session.
I don't know what that indicates but we should bring
it to JOQ's attention or probably CC to the jack
developer list.
ron
Then I introduced jamin - 4 xruns in 8 mins.
Shut down jamin and go back to only ardour - more
xruns.
Shut down all but essential services and only use
ardour - more xruns.
Seems that a bottle of xruns was opened and I
can't put the cap back on.
I then changed jack settings to 256/44100/2 and
the xruns went away while
only using ardour.
Brad, I'm curious: did you stop and start JACK
after you closed out
JAMin and/or Ardour? I did a session over the
weekend where I had a
problem with Ardour, and would have to exit. If I
didn't restart JACK
as well, I ran into issues. (I wish I could be
clearer on this, but I
left my notes at home regarding this.) --
======================================================================
Joe Hartley - UNIX/network Consultant -
jh(a)brainiac.com
Without deviation from the norm, "progress" is not
possible. - FZappa
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
8:10 p.m.
Last Wednesday 29 September 2004 15:41, Joe Hartley was like:
Brad, I'm curious: Â did you stop and start JACK
after you closed out
JAMin and/or Ardour? Â I did a session over the weekend where I had a
problem with Ardour, and would have to exit. Â If I didn't restart JACK
as well, I ran into issues. Â (I wish I could be clearer on this, but I
left my notes at home regarding this.)
This is a phenomenon I'm familiar with. I have no idea of the technicalities,
it's generally the rule that once JACK has got seriously out of step, it
needs restarting to get it play ball. It usually recovers after the first
dozen, but once it's gone over the edge, there's generally no getting it
back.
Yes I'm using a low-latency patched kernel and my system is averagely well
optimised. (Celeron 600 + 256M RAM)
Brad, the way out of optimisationitis is to Actually Make Some Music -
conceive some grand piece and realise it, put your energies into seeing what
you can do with what you've got. I just managed to master an entire album
with JAMin on _my_ hardware !:-) Suffice it to say it was a fine a thing as
having to close all the dialogs in QJackCtl and stop gkrellm before I was
xrun free - all those updating monitors really make a difference on my
system. I'd already closed down everything else I could think of.
It would be impossible without a low-lat kernel, I'm sure, but even that does
require a certain amount of CPU headroom ;-]
Apologies for technical fluffiness.
cheers
tim hall
6:52 p.m.
On Wed, 2004-09-29 at 07:28, Brad Stafford wrote:
Since I gave such a glowing review of my testing the
other night that I
thought I'd report back my not so stellar results from last night.
I left all the services running on a fully loaded machine (http, iptables,
sendmail, samba, etc...) and started jack at 128/44100/2 in real time. I
started a 20 minute recording session with ardour (no jamin yet). While
ardour was recording I dialed into the internet with my modem, opened
evolution, read email and poked around a bit with konqueror. I got zero,
nada, nil, none, no xruns whatsoever.
Then I introduced jamin - 4 xruns in 8 mins.
Shut down jamin and go back to only ardour - more xruns.
Shut down all but essential services and only use ardour - more xruns.
Seems that a bottle of xruns was opened and I can't put the cap back on.
I have seen this happen. What processor are you using? Does the cpu load
jump up (and stay up) when you enter in this "xrun mode"?
-- Fernando
7:01 p.m.
Hey Nando,
I'm running an AMD Barton 2.6 GHz processor. I'll watch for processor load
tonight when I try to replicate the problem.
Thanks for the tip.
Brad.
----- Original Message -----
From: "Fernando Pablo Lopez-Lezcano" <nando(a)ccrma.stanford.edu>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Wednesday, September 29, 2004 3:35 PM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
On Wed, 2004-09-29 at 07:28, Brad Stafford wrote:
> Since I gave such a glowing review of my testing the other night that I
> thought I'd report back my not so stellar results from last night.
>
> I left all the services running on a fully loaded machine (http,
iptables,
sendmail,
samba, etc...) and started jack at 128/44100/2 in real time. I
started a 20 minute recording session with ardour (no jamin yet). While
ardour was recording I dialed into the internet with my modem, opened
evolution, read email and poked around a bit with konqueror. I got zero,
nada, nil, none, no xruns whatsoever.
Then I introduced jamin - 4 xruns in 8 mins.
Shut down jamin and go back to only ardour - more xruns.
Shut down all but essential services and only use ardour - more xruns.
Seems that a bottle of xruns was opened and I can't put the cap back on.
I have seen this happen. What processor are you using? Does the cpu load
jump up (and stay up) when you enter in this "xrun mode"?
-- Fernando
30 Sep
30 Sep
12:02 p.m.
On Wed, 2004-09-29 at 07:28, Brad Stafford wrote:
>
> Then I introduced jamin - 4 xruns in 8 mins.
>
> Shut down jamin and go back to only ardour - more xruns.
>
> Shut down all but essential services and only use ardour - more xruns.
Is it possible not all pids were killed when you shut some of those
down?
I bring this up because I've had exactly that experience more than once
with various apps. At one time or another I've shut something down only
to find that my system doesn't behave properly. Lo and behold, a ps aux
has sometimes revealed pids that should have been cleared are, in fact,
still there. I've had to kill -9 them to get things back.
I'd suggest not trusting the user-friendly scripts and higher-level
viewing tools, but rather looking to the source in this situation.
29 Sep
29 Sep
1:41 p.m.
On Wed, 2004-09-29 at 09:55, Mark Knecht wrote:
Lee Revell wrote:
It looks like about one microsecond to dispatch the irq to the correct
handler. Mouse activity produces at most a 20-30 usec delay in jackd,
regardless of whether the interrupt is shared. So this matches my other
estimate of 50 usecs or so in the USB interrupt handler.
Oops, sorry, I meant microseconds. I was
actually looking at a trace
when I wrote this, and Ingo's tracer prints milliseconds, and I screwed
up the conversion. It looks like 2-3 usecs to determine where the
interrupt came from if two devices share an irq.
Thanks Lee. That's very compatible with my back-of-the-envelope
calculations. However, I believe that number assumes that the leading
interrupt device is not interrupting and you only had to determine that
the real interrupt came from the sound card. Assuming a shared
interrupt, and assuming that a USB controller is the first and the sound
card is the second device, what delay is encountered by the sound card
when both devices interrupt at the same time?
I understand that there is probably a few microseconds extra delay as
the system determines that there are two interrupt devices pending. How
long is it, however, before the UCB interrupt handler does all it's work
and hands off to the sound card interrupt handler (or sound card driver)
so that it can get started?
I grant you that this will should not amount to 500uS
worth of delay,
but then we need to add in the possibilities of other, higher priority
interrupts coming along during that window and further delaying the
sound card getting it's work don before the Jack frame runs out.
This is the beauty of the 2.6 kernel with the VP patches. If you
configure the IRQ threading correctly, it is impossible for interrupts
from other IRQ lines to interrupt the sound card at all. The only thing
that can delay the sound card interrupt is if the system is already
processing another interrupt from the same line (like, say, USB). Since
the USB irq handler is very fast, this should never be a problem.
For me this is not a mere curiosity. Yesterday I
brought up FC2 and
then, with much help from Steve Harris and Fernando, got a new Planet
kernel installed. No sooner than I had started Jack I then started using
my USB mouse and getting huge xruns. Since USB is shared with the sound
chip I think it's an example of what we ae talking about here.
Not quite. If you have a USB sound card it's a different ball game,
because you don't just have two separate devices sharing the interrupt,
you actually have them competing for USB bus bandwidth. Although it
should work if they are on different USB controllers. Unfortunately I
am not an expert on USB so I can't help much more.
Lee
2 p.m.
Lee Revell wrote:
It is a PCI sound chip sharing an interrupt with a PCI USB OHCI (EHCI?)
contoller. There is no sharing of USB bandwidth. Sorry - that was
badly worded before...
On Wed, 2004-09-29 at 09:55, Mark Knecht wrote:
For me this is
not a mere curiosity. Yesterday I brought up FC2 and
then, with much help from Steve Harris and Fernando, got a new Planet
kernel installed. No sooner than I had started Jack I then started using
my USB mouse and getting huge xruns. Since USB is shared with the sound
chip I think it's an example of what we ae talking about here.
Not quite. If you have a USB sound card it's a different ball game,
because you don't just have two separate devices sharing the interrupt,
you actually have them competing for USB bus bandwidth. Although it
should work if they are on different USB controllers. Unfortunately I
am not an expert on USB so I can't help much more.
Lee
2:37 p.m.
On Wed, 2004-09-29 at 11:42, Mark Knecht wrote:
Lee Revell wrote:
On Wed, 2004-09-29 at 09:55, Mark Knecht wrote:
>>For me this is not a mere curiosity. Yesterday I brought up FC2 and
>>then, with much help from Steve Harris and Fernando, got a new Planet
>>kernel installed. No sooner than I had started Jack I then started using
>>my USB mouse and getting huge xruns. Since USB is shared with the sound
>>chip I think it's an example of what we ae talking about here.
>
>
> Not quite. If you have a USB sound card it's a different ball game,
> because you don't just have two separate devices sharing the interrupt,
> you actually have them competing for USB bus bandwidth. Although it
> should work if they are on different USB controllers. Unfortunately I
> am not an expert on USB so I can't help much more.
> It is a PCI sound chip sharing an interrupt with a PCI
USB OHCI (EHCI?)
contoller. There is no sharing of USB bandwidth. Sorry - that was
badly worded before...
Thanks for clarifying, I re-read your message and realized you might not
have a USB sound device. Anyway, if by "new Planet kernel" you mean 2.6
with the VP patches, then mouse activity should not be causing xruns.
I am not on the CCRMA list; if you have already posted your details then
send a link. This should be investigated further as it definitely
should work.
Lee
3:20 p.m.
Lee Revell wrote:
On Wed, 2004-09-29 at 11:42, Mark Knecht wrote:
Thanks Lee. I've put a very sparce first post up on the Planet list. I
see that Fernando has already answered although I had not received the
response here just yet:
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-September/006162.…
I did try setting the THREADED operator back to 1. That didn't change
anything for me. Fernando's suggestion to look at his newer kernel will
be addressed early this afternoon.
As background, this is a clean install of FC2 on a machine that also
runs Win XP Pro and Gentoo. It's running KDE which I'm not overly
familiar with anymore. I've attempted to follow Fernando's suggestions
in this email:
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-August/005789.html
except that I used a newer kernel of his. (But not the newest...)
There are a few tools I'm used to under Gentoo, usbview most notibly,
that I haven't found yet under FC2, and I'm still getting used to where
things are. (lsmod for instance...) I may or may not have accomplished
all of his tuning suggestions in the above email, and I have to reread
the Planet pages to see what does and does not apply to using FC2. I
think this is where things are now, but it needs to be double checked:
kernel_preemption == 1
voluntary_preemption == 3
threaded IRQ for the ATI chip == 0 or 1 (no change)
sysrq == 1 (Not sure - haven't checked if it sticks after a reboot)
/sbin/modprobe realcap allcaps=1 (by hand after booting)
That's where I am at this point. I just started with FC2 yesterday
morning so I'm not expecting much yet, but hopefully over the next few days.
Thanks for paying attention. I appreciate it.
cheers,
Mark
It is a PCI sound chip sharing an interrupt with a
PCI USB OHCI (EHCI?)
contoller. There is no sharing of USB bandwidth. Sorry - that was
badly worded before...
Thanks for clarifying, I re-read your message and realized you might not
have a USB sound device. Anyway, if by "new Planet kernel" you mean 2.6
with the VP patches, then mouse activity should not be causing xruns.
I am not on the CCRMA list; if you have already posted your details then
send a link. This should be investigated further as it definitely
should work.
Lee
28 Sep
28 Sep
11:41 p.m.
On Tue, 2004-09-28 at 18:05, Mark Knecht wrote:
No, this does not cause an xrun, because even though the USB interrupt
handler interrupts the soundcard irq (and vice versa), it does not run
for a significant fraction of the period time. Of course it's best to
have the soundcard on an interrupt that is not shared. But whether that
interrupt is #5 or #10 does not matter.
Great. Just checking. (You did *actually* do it, right?) ;-)
Ok, I repeated this test just now (I had actually done it, but weeks
ago). It does not make a difference at all if I plug the mouse into the
front USB port (shared with the soundcard) or the rear one (not shared).
This is with the soundcard and mouse on different IRQs:
load = 1.3880 max usecs: 7.000, spare = 659.000
load = 1.2195 max usecs: 7.000, spare = 659.000
load = 1.1353 max usecs: 7.000, spare = 659.000
load = 1.8439 max usecs: 17.000, spare = 649.000 <-- start moving mouse
load = 1.6727 max usecs: 10.000, spare = 656.000
load = 2.3379 max usecs: 20.000, spare = 646.000
load = 2.5954 max usecs: 19.000, spare = 647.000 <-- stop moving mouse
load = 1.8983 max usecs: 8.000, spare = 658.000
load = 1.4747 max usecs: 7.000, spare = 659.000
load = 1.2629 max usecs: 7.000, spare = 659.000
Here is the mouse and soundcard sharing an IRQ:
load = 1.2021 max usecs: 8.000, spare = 658.000
load = 1.2017 max usecs: 8.000, spare = 658.000
load = 1.2014 max usecs: 8.000, spare = 658.000
load = 1.8770 max usecs: 17.000, spare = 649.000 <-- start moving mouse
load = 2.4400 max usecs: 20.000, spare = 646.000
load = 2.7215 max usecs: 20.000, spare = 646.000
load = 2.7121 max usecs: 18.000, spare = 648.000 <-- stop moving mouse
load = 1.9567 max usecs: 8.000, spare = 658.000
load = 1.5789 max usecs: 8.000, spare = 658.000
load = 1.3901 max usecs: 8.000, spare = 658.000
So, the interrupt response is about a microsecond faster with them on
different IRQs. This is what I expected (but I did not expect it to
show up in jackd -v!). And, regardless of whether the interrupt is
shared, mouse activity will only delay jackd by about 20 microseconds.
These numbers all support my original point that tweaking your
interrupts is a waste of time, you should be installing a low latency
kernel instead...
rlrevell@mindpipe:~$ uname -r
2.6.9-rc2-mm3-VP-S6
Lee
Lee Revell wrote:
> On Tue, 2004-09-28 at 16:11, Mark Knecht wrote:
>>Lee Revell wrote:
I get no xruns
at 32 (!) frames using 2.6 with the VP patches,
and my soundcard shares an interrupt with USB:
(Non-argumentive if it's unclear) Please stick a USB mouse on the USB
port that is shared and wiggle it madly while doing some of this. Can
you create an xrun?
>
8:02 p.m.
Hey Ron,
I was misinterpreting your statements. You
couldn't
reliably run 128 frames with with RH9 and 2.4 kernel.
Is that correct?
That is correct.
Have you done any tests with Ardour and JAMin at 128
frames?
Last night I cranked up Jack and started Ardour and opened six mono
channels and would let it run for 15 - 20 mins several times without a
single xrun. Then it got to be about ... oh 1:00 am. I didn't introduce
Jamin last night but I will tonight. I'm on a modem at home so I had to
bring my PC into work today to download the lastest updates from the CCRMA
site.
I also agree with you that I really don't want a single xrun. I have a
recording session coming up this weekend and I'm *REALLY* happy I moved to
FC1. I built temporary walls stuffed with insulation that transformed the
kitchen into studio "A", the dining room into studio "B" and the
living room
is now studio "C". The laundry room is the control room .. :-))
Brad.
----- Original Message -----
From: "R Parker" <rtp405(a)yahoo.com>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Tuesday, September 28, 2004 10:40 AM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
> Hi Brad,
>
> > > > I'm getting 5.8 msec latency in JACK with 128
> > frames/period at 44100 and
> > > > 2 periods/buffer. A huge improvement over the
> > 46.1 msec using RH9 with
> > > > capabilities.
>
> I'm confused. jackstart -R -p512 -dalsa -dhw:0 -r44100
> -p128 -n2 is 5.8 msec of latency and it can't be
> anything else. The issue is whether or not the system
> will perform reliably with these settings.
>
> I was misinterpreting your statements. You couldn't
> reliably run 128 frames with with RH9 and 2.4 kernel.
> Is that correct? Doh, I went and deleted the rest of
> your message--the improved low buffer size reliability
> is in a FC2/2.6 kernel?
>
Have you done any tests with Ardour and JAMin at 128
frames?
>
> Well, those are encouraging improvements.
>
> With my setup, I'm getting decent enough reliability
> at 128 frames but when I record and mix, I turn it
> back to 1024. Under no circumstances can I tolerate a
> single xrun.
>
> ron
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
29 Sep
29 Sep
5:21 a.m.
On Tuesday 28 September 2004 07:48 am, Brad Stafford wrote:
Thanks Mark and Russell for the reply. I'll be
happy with what I have and
stop trying to get latency into the negative range (if something happens in
the forest before it happens did it really happen?)
LOL! Now that's funny! :) And it's late and I need to go beddy byes!
YW!
R~
I'll go make music now... I'm one happy tweak-head!
Brad.
----- Original Message -----
From: "Russell Hanaghan" <hanaghan(a)starband.net>
To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Tuesday, September 28, 2004 1:42 AM
Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
--
The Road of Life is paved with Squirrels that couldn't make a decision!
On Monday 27 September 2004 10:59 pm, brad
stafford wrote:
and I
I just tonight switched from the Planet CCRMA RH9
to FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and
I'm running an AMD Barton 2.6 with 5 PCI slots. The question is what
the heck are IRQ 16 and 22? I moved the sound and ethernet cards around
to get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on
22. I have ACPI turned off as a service but don't have a "disable"
option in the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100
and 2 periods/buffer. A huge improvement over the 46.1 msec using RH9
with capabilities.
Thanks, Brad.
To semi paraphrase something I think Mr. Knecht conveyed nicely earlier, also believe with much merit...and in my own
short but sweet format...
Unless your box has plumes of dark grey smoke billowing from it because
of
the
Xruns overload {Well, Athalon does run hot....it
could happen} or...
The sound is so choppy, it sounds like an extratarestrial life form is
trying
to contact you or...
you just ~can't~ sleep at night bareing the thought of a single Xrun
passing
b4 your eyes...
And assuming your sound is clean and glitchless...I gotta say...If you
are getting 5.8 msec @ 128x2 with clean sound and a stable, happy
jack...other than those pesky lil' "0 (0)" buggers in the Qjackctl window
turnng red on you...Just BACK AWAY FROM THE INTERRUPTS MR.!!!....Put
those pci cards
down
nice and slow and get them hands up where we can
see 'em! Put the cover
BACK
on the machine and record 3 verses of
"Don't worry, Be happy"!
I am also using a Delta 1010LT on an Athalon Barton chip with a tad less
than
1gig DDR 2700 ram. I screwed with it endlessly
seeking that "super setup"
you know...the setup so clean the bugger will compose, record and mix the
music all by itself...And I wasted LOTS of damn time I could have spent
doing
what WE ACTUALLY are meant to do this
for...CREATE MUZIC! :)
I run the 2.6 kernel with Realtime-lsm as my only real latency
improvement patch {and whatever other bits 'n' pieces Thac's sticks in
his kernels} I have been recording in Ardour at 256x2. If the dang Xruns
start to give me the urge to break a perfectly good working DAW, I put
the SOB in "soft mode"! :) No mo' Xruns! And the recording, even running
plugins whilst recording, is perfectly acceptable.
The point I'm trying to make is...apply some attention to tweaking your
box
but not to the point of distraction. If it's
working well, I don't care
if
my
> soundcard is on INT 204! {eh hem} :)
>
> Happy recording and music making!!
>
> R~
>
> --
> The Road of Life is paved with Squirrels that couldn't make a decision! 
28 Sep
28 Sep
10:44 a.m.
brad stafford wrote:
I have a Delta 1010 and I'm running an AMD Barton
2.6 with 5 PCI
slots. The question is what the heck are IRQ 16 and 22?
IRQ 16 is the 17th interrupt.
IRQ 22 is the 23th interrupt.
I moved the sound and ethernet cards around to get
them to 16 and
22 as they used to be eth0 on 21 and ICE1712 on 22.
[brad@mars brad]$ cat /proc/interrupts
CPU0
...
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
Why? What's the problem?
Is 16 like the equivalent of IRQ 3 since it's
following 15?
No, it would be correct to say that IRQ 16 is IRQ 16. ;-)
The days of XT-compatible interrupt controllers with no more than 16
interrupts are fortunately past. The interrupts above 15 are used for
PCI devices.
I did turn off USB support in the BIOS.
USB interrupts usually don't cause noticeable latencies.
HTH
Clemens
11:54 a.m.
brad stafford wrote:
I just tonight switched from the Planet CCRMA RH9 to
FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
Brad,
First I see no reason for you to change anything. If there's no
problem to fix, then why make a problem?
Interrupts, in your case, are based on the APIC model. You machine
has an APIC (Advanced Programmable Interrupt Controller) as well as one
or more IO-APIC chips, so it supports more than the old style 15
interrupts. This is not a problem. It should be an advantage, if
everything is set up correctly.
My input would be to go with the flow. If one of these days you find
that you are getting worse performance, be it xruns or something else,
then come back and let's look at the setup of the machine. Until then,
be happy. It looks like the results are quite good, right?!?
Cheers,
Mark
3:14 p.m.
Mark Knecht wrote:
brad stafford wrote:
One last little sickening detail I forgot to add before. Sorry for doing
it now.
In the older 'compatibility model' we knew the 'prioity of the interrupt
from the interrupt number: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was
hardwired.
In the newer 'APIC' model all we know is the interrupt number, not the
priority. There is a secondary routing table that maps the interrupt
priority using a vector. The table is visible in dmesg on my machines.
It probably is on yours also. The meaning of the table is obscure and
has been covered here before. The 'unfortunate' aspect of the table is
that there are no generally avaialble tools to allow a system
administrator to modify the vectors and hence change the priorities of a
given hardware device. Not sure that matters to most people. I would be
happier having that capability and hope it will appear one day.
Sorry for chiming in again.
- Mark
I just tonight switched from the Planet CCRMA RH9
to FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
Brad,
First I see no reason for you to change anything. If there's no
problem to fix, then why make a problem?
Interrupts, in your case, are based on the APIC model. You machine
has an APIC (Advanced Programmable Interrupt Controller) as well as one
or more IO-APIC chips, so it supports more than the old style 15
interrupts. This is not a problem. It should be an advantage, if
everything is set up correctly.
My input would be to go with the flow. If one of these days you find
that you are getting worse performance, be it xruns or something else,
then come back and let's look at the setup of the machine. Until then,
be happy. It looks like the results are quite good, right?!?
Cheers,
Mark
3:41 p.m.
On Tue, 28 Sep 2004 09:57:15 -0700
Mark Knecht <mknecht(a)controlnet.com> wrote:
One last little sickening detail I forgot to add
before. Sorry for
doing it now.
In the older 'compatibility model' we knew the 'prioity of the
interrupt from the interrupt number:
0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was hardwired.
Hi,
i welcome your chiming in because now you got me confused :)
http://roht.informatik.uni-halle.de/~ladischc/pic_priorities.html
That page says one can change the irq prios directly in the PIC. So, are
they hardwired now, or not?
Flo
4:17 p.m.
Florian Schmidt wrote:
On Tue, 28 Sep 2004 09:57:15 -0700
Mark Knecht <mknecht(a)controlnet.com> wrote:
Florian,
It may be possible to change the priorities in the the old PIC
model. I do not know of anyone that actually does it nor do I know what
the real world implications of doing it might be.
It is my understand that in a 'IBM Compatible PC' that the interrupt
priorities are never changed. I suppose it's possible that the
capability exists to do so but that no one really uses it.
I do know that the ability to change the priorities is considered
one advantage of the newer APIC model.
Of course, I could be quite wrong!! Take it all with a grain of salt!
Cheers,
Mark
One last little sickening detail I forgot to add
before. Sorry for
doing it now.
In the older 'compatibility model' we knew the 'prioity of the
interrupt from the interrupt number:
0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was hardwired.
Hi,
i welcome your chiming in because now you got me confused :)
http://roht.informatik.uni-halle.de/~ladischc/pic_priorities.html
That page says one can change the irq prios directly in the PIC. So, are
they hardwired now, or not?
Flo
29 Sep
29 Sep
5:23 a.m.
On Tuesday 28 September 2004 09:57 am, Mark Knecht wrote:
Mark Knecht wrote:
Aieeee! And we almost got away clean too! :)
R~
--
The Road of Life is paved with Squirrels that couldn't make a decision!
brad stafford wrote:
One last little sickening detail I forgot to add before. Sorry for doing
it now.
In the older 'compatibility model' we knew the 'prioity of the interrupt
from the interrupt number: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was
hardwired.
In the newer 'APIC' model all we know is the interrupt number, not the
priority. There is a secondary routing table that maps the interrupt
priority using a vector. The table is visible in dmesg on my machines.
It probably is on yours also. The meaning of the table is obscure and
has been covered here before. The 'unfortunate' aspect of the table is
that there are no generally avaialble tools to allow a system
administrator to modify the vectors and hence change the priorities of a
given hardware device. Not sure that matters to most people. I would be
happier having that capability and hope it will appear one day.
Sorry for chiming in again.
- Mark I just tonight switched from the Planet CCRMA RH9
to FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
Brad,
First I see no reason for you to change anything. If there's no
problem to fix, then why make a problem?
Interrupts, in your case, are based on the APIC model. You machine
has an APIC (Advanced Programmable Interrupt Controller) as well as one
or more IO-APIC chips, so it supports more than the old style 15
interrupts. This is not a problem. It should be an advantage, if
everything is set up correctly.
My input would be to go with the flow. If one of these days you find
that you are getting worse performance, be it xruns or something else,
then come back and let's look at the setup of the machine. Until then,
be happy. It looks like the results are quite good, right?!?
Cheers,
Mark 
28 Sep
28 Sep
11:32 p.m.
brad stafford wrote:
I just tonight switched from the Planet CCRMA RH9 to
FC1. The install
was purely from the CDROMs dated 4/25/2004.
I've seen all the latest posts about interrupts and did the required
reading on the internet. I really managed to get RH9 cleaned up but in
FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
running an AMD Barton 2.6 with 5 PCI slots. The question is what the
heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
have ACPI turned off as a service but don't have a "disable" option in
the BIOS. I did turn off USB support in the BIOS.
Is 16 like the equivalent of IRQ 3 since it's following 15?
[brad@mars brad]$ cat /proc/interrupts
CPU0
0: 81690 IO-APIC-edge timer
1: 75 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 836 IO-APIC-edge PS/2 Mouse
14: 10789 IO-APIC-edge ide0
15: 735 IO-APIC-edge ide1
16: 0 IO-APIC-level ICE1712
22: 21 IO-APIC-level eth0
NMI: 0
LOC: 81633
ERR: 0
MIS: 0
I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
capabilities.
Thanks, Brad.
You can add the "acpi=off" option to the kernel argument boot line
in grub.conf like so:
kernel /vmlinuz-2.4.26-1.ll.rhfc1.ccrma ro root=/dev/hda2 hdc=ide-scsi
acpi=off nolapic rhgb
That will get rid of interrupts 16 and 22 and move your soundcard and
ethernet card to *maybe* a more desirable position like IRQ 10 & 11. But
after reading the other posts in this thread I question if it really
makes any difference.
Rick B
7388
days inactive
7390
days old
linux-audio-user@lists.linuxaudio.org
33 comments
13 participants
participants (13)
-
brad stafford -
Clemens Ladisch -
Fernando Pablo Lopez-Lezcano -
Florian Schmidt -
Janina Sajka -
Joe Hartley -
Lee Revell -
Mark Knecht -
Mark Knecht -
R Parker -
Rick B -
Russell Hanaghan -
tim hall