Discussion:
[LAU] eliminating xruns on 64-bit Arch ?
(too old to reply)
Dave Phillips
2011-12-14 12:55:37 UTC
Permalink
Greetings,

I like my Arch system, but its rt performance is simply not so good as
my old 64 Studio installation. I think I have it optimized, but I wonder
if there isn't more I could do to eradicate the occurrrence of xruns
when recording with Ardour. Technical details follow.

uname -a reports these facts :

Linux BigBlack 3.0-ARCH #1 SMP PREEMPT x86_64 AMD Athlon(tm) 64
Processor 3200+

The relevant entries in /etc/security/limits.conf

@audio - rtprio 99
@audio - nice -10
@audio - memlock unlimited

I know about nice. IIRC these settings were default values.

The hardware is an M-Audio Delta 66 system, with a separate preamp. Some
relevant JACK (0.121.3) settings :

/usr/bin/jackd -P89 -t5000 -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq

I usually get two or three xruns per half-hour session, as compared to 0
with 64 Studio. Btw, I'm not comparing the distros, just the performance
stats. I have no interest in returning to older systems, but I have much
interest in improving the ones I'm running now.

This bothers me :

[***@BigBlack etc]$ cat /proc/interrupts
CPU0
0: 50 IO-APIC-edge timer
1: 4 IO-APIC-edge i8042
7: 1 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 6 IO-APIC-edge i8042
14: 0 IO-APIC-edge pata_amd
15: 27164 IO-APIC-edge pata_amd
16: 788897 IO-APIC-fasteoi ICE1712, nvidia <---- Ouch !!!
17: 144 IO-APIC-fasteoi firewire_ohci
20: 49995 IO-APIC-fasteoi ohci_hcd:usb2
21: 87877 IO-APIC-fasteoi sata_nv
22: 2124 IO-APIC-fasteoi sata_nv, hda_intel
23: 82436 IO-APIC-fasteoi ehci_hcd:usb1, eth0

Yep, that's my video card. Can I reassign the IRQ - preferably via
software - for one of those devices ? If so, how and in what order ? I
know about the rtirq script but there seems to little information
regarding its use with a kernel such as mine (Rui ?). Btw, I know that
an updated kernel is available from pacman and will gladly install it if
recommended.

Please advise if other information is required.

Suggestions and recommendations are most welcome. However, before
recommending an rt kernel please note that I need hardware accelerated
3D. Ditching the nVidia binary is not really an option yet, so any
suggested kernel must get along with the nVidia driver.

Best,

dp
Florian Paul Schmidt
2011-12-14 13:52:07 UTC
Permalink
Post by Dave Phillips
Suggestions and recommendations are most welcome. However, before
recommending an rt kernel please note that I need hardware accelerated
3D. Ditching the nVidia binary is not really an option yet, so any
suggested kernel must get along with the nVidia driver.
Hi,

back when I heavily used -rt kernels it was mostly a matter recompiling
the open source part of the proprietary nvidia-drivers against that
kernel to get the 3D-acceleration going again. You still have a tainted
kernel, but in practice it worked great.

Flo
Jeremy Jongepier
2011-12-14 13:58:40 UTC
Permalink
Post by Dave Phillips
Greetings,
I like my Arch system, but its rt performance is simply not so good as
my old 64 Studio installation.
Hello Dave,

Yeah, Arch is nice, I'm in the process of building up an Arch audio
machine too.

I think I have it optimized, but I wonder
Post by Dave Phillips
if there isn't more I could do to eradicate the occurrrence of xruns
when recording with Ardour. Technical details follow.
Linux BigBlack 3.0-ARCH #1 SMP PREEMPT x86_64 AMD Athlon(tm) 64
Processor 3200+
The relevant entries in /etc/security/limits.conf
@audio - rtprio 99
@audio - nice -10
@audio - memlock unlimited
You could check /etc/security/limits.d/99-audio-conf
I wonder though if both files exist if they don't conflict. What does
ulimit -r -m output?
Post by Dave Phillips
I know about nice. IIRC these settings were default values.
The hardware is an M-Audio Delta 66 system, with a separate preamp. Some
/usr/bin/jackd -P89 -t5000 -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq
The seq driver can cause xruns. You can rule it out as a possible cause
by using a2jmidid.
Post by Dave Phillips
I usually get two or three xruns per half-hour session, as compared to 0
with 64 Studio. Btw, I'm not comparing the distros, just the performance
stats. I have no interest in returning to older systems, but I have much
interest in improving the ones I'm running now.
CPU0
0: 50 IO-APIC-edge timer
1: 4 IO-APIC-edge i8042
7: 1 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 6 IO-APIC-edge i8042
14: 0 IO-APIC-edge pata_amd
15: 27164 IO-APIC-edge pata_amd
16: 788897 IO-APIC-fasteoi ICE1712, nvidia <---- Ouch !!!
17: 144 IO-APIC-fasteoi firewire_ohci
20: 49995 IO-APIC-fasteoi ohci_hcd:usb2
21: 87877 IO-APIC-fasteoi sata_nv
22: 2124 IO-APIC-fasteoi sata_nv, hda_intel
23: 82436 IO-APIC-fasteoi ehci_hcd:usb1, eth0
Yep, that's my video card. Can I reassign the IRQ - preferably via
software - for one of those devices ?
No, afaik only if your system supports MSI and it looks like it doesn't
(unless you didn't post the whole output). But I'm no expert on this so
I could be mistaken. You could try swapping ports for the ICE1712.

If so, how and in what order ? I
Post by Dave Phillips
know about the rtirq script but there seems to little information
regarding its use with a kernel such as mine (Rui ?).
With your current non-rt kernel you have to use the threadirqs kernel
option.
Jeremy Jongepier
2011-12-14 14:09:51 UTC
Permalink
Post by Jeremy Jongepier
No, afaik only if your system supports MSI and it looks like it doesn't
(unless you didn't post the whole output). But I'm no expert on this so
I could be mistaken. You could try swapping ports for the ICE1712.
Sorry to reply to myself, but it's the device that uses MSI:
http://en.wikipedia.org/wiki/Message_Signaled_Interrupts

Best,

Jeremy
Dave Phillips
2011-12-14 14:42:03 UTC
Permalink
Post by Jeremy Jongepier
Post by Dave Phillips
The relevant entries in /etc/security/limits.conf
@audio - rtprio 99
@audio - nice -10
@audio - memlock unlimited
You could check /etc/security/limits.d/99-audio-conf
I wonder though if both files exist if they don't conflict. What does
ulimit -r -m output?
It checks out:

[***@BigBlack ~]$ ulimit -r -m
real-time priority (-r) 99
max memory size (kbytes, -m) unlimited
Post by Jeremy Jongepier
Post by Dave Phillips
The hardware is an M-Audio Delta 66 system, with a separate preamp. Some
/usr/bin/jackd -P89 -t5000 -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq
The seq driver can cause xruns. You can rule it out as a possible
cause by using a2jmidid.
Ah, okay, it's removed. I'll test later this afternoon, can't use the
recorder at the moment.
Post by Jeremy Jongepier
Post by Dave Phillips
I usually get two or three xruns per half-hour session, as compared to 0
with 64 Studio. Btw, I'm not comparing the distros, just the performance
stats. I have no interest in returning to older systems, but I have much
interest in improving the ones I'm running now.
CPU0
0: 50 IO-APIC-edge timer
1: 4 IO-APIC-edge i8042
7: 1 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 6 IO-APIC-edge i8042
14: 0 IO-APIC-edge pata_amd
15: 27164 IO-APIC-edge pata_amd
16: 788897 IO-APIC-fasteoi ICE1712, nvidia <---- Ouch !!!
17: 144 IO-APIC-fasteoi firewire_ohci
20: 49995 IO-APIC-fasteoi ohci_hcd:usb2
21: 87877 IO-APIC-fasteoi sata_nv
22: 2124 IO-APIC-fasteoi sata_nv, hda_intel
23: 82436 IO-APIC-fasteoi ehci_hcd:usb1, eth0
Yep, that's my video card. Can I reassign the IRQ - preferably via
software - for one of those devices ?
No, afaik only if your system supports MSI and it looks like it
doesn't (unless you didn't post the whole output). But I'm no expert
on this so I could be mistaken. You could try swapping ports for the
ICE1712.
I'm considering it. IIRC there are only two or three PCI slots on the
mobo, and the nVidia card is in a PCIe slot.
Post by Jeremy Jongepier
Post by Dave Phillips
know about the rtirq script but there seems to little information
regarding its use with a kernel such as mine (Rui ?).
With your current non-rt kernel you have to use the threadirqs kernel
option.
Jeremy Jongepier
2011-12-15 14:21:17 UTC
Permalink
Post by Jeremy Jongepier
Post by Dave Phillips
The relevant entries in /etc/security/limits.conf
@audio - rtprio 99
@audio - nice -10
@audio - memlock unlimited
You could check /etc/security/limits.d/99-audio-conf
I wonder though if both files exist if they don't conflict. What does
ulimit -r -m output?
real-time priority (-r) 99
max memory size (kbytes, -m) unlimited
Hello Dave,

So the correct settings get picked up, they should have otherwise you
couldn't run JACK with your current settings.
Post by Jeremy Jongepier
Post by Dave Phillips
The hardware is an M-Audio Delta 66 system, with a separate preamp. Some
/usr/bin/jackd -P89 -t5000 -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq
The seq driver can cause xruns. You can rule it out as a possible
cause by using a2jmidid.
Ah, okay, it's removed. I'll test later this afternoon, can't use the
recorder at the moment.
Post by Jeremy Jongepier
Post by Dave Phillips
I usually get two or three xruns per half-hour session, as compared to 0
with 64 Studio. Btw, I'm not comparing the distros, just the performance
stats. I have no interest in returning to older systems, but I have much
interest in improving the ones I'm running now.
CPU0
0: 50 IO-APIC-edge timer
1: 4 IO-APIC-edge i8042
7: 1 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 6 IO-APIC-edge i8042
14: 0 IO-APIC-edge pata_amd
15: 27164 IO-APIC-edge pata_amd
16: 788897 IO-APIC-fasteoi ICE1712, nvidia <---- Ouch !!!
17: 144 IO-APIC-fasteoi firewire_ohci
20: 49995 IO-APIC-fasteoi ohci_hcd:usb2
21: 87877 IO-APIC-fasteoi sata_nv
22: 2124 IO-APIC-fasteoi sata_nv, hda_intel
23: 82436 IO-APIC-fasteoi ehci_hcd:usb1, eth0
Yep, that's my video card. Can I reassign the IRQ - preferably via
software - for one of those devices ?
No, afaik only if your system supports MSI and it looks like it
doesn't (unless you didn't post the whole output). But I'm no expert
on this so I could be mistaken. You could try swapping ports for the
ICE1712.
I'm considering it. IIRC there are only two or three PCI slots on the
mobo, and the nVidia card is in a PCIe slot.
Post by Jeremy Jongepier
Post by Dave Phillips
know about the rtirq script but there seems to little information
regarding its use with a kernel such as mine (Rui ?).
With your current non-rt kernel you have to use the threadirqs kernel
option.
Mac
2011-12-15 12:52:27 UTC
Permalink
Date: Thu, 15 Dec 2011 07:49:23 -0500
Subject: Re: eliminating xruns on 64-bit Arch ?
Subject: [LAU] eliminating xruns on 64-bit Arch ?
<snip>
Greetings,
I like my Arch system, but its rt performance is simply not so good as
my old 64 Studio installation. I think I have it optimized, but I wonder
if there isn't more I could do to eradicate the occurrrence of xruns
when recording with Ardour. Technical details follow.
A couple years back I did a lot of this sort of parameter adjusting
to get Ubuntu Studio (vintage 9.x) to work with
as few xruns as possible with 2 AF12's.

After getting it running I did the same in vintage UB Studio 10.x, but
could never get it to the point of no xruns in a 2 hour recording.

I then stumbled on AVLinux. I installed it, fired up Jack and
Ardour...and it just worked. So that's what I've been using for
sometime now.

This is of course a single data point and I have not had the occasion
to do try anything with later releases. So: YMMV , caveat emptor.

Regards,
Mac
Dave Phillips
2011-12-15 13:21:02 UTC
Permalink
...I then stumbled on AVLinux. I installed it, fired up Jack and
Ardour...and it just worked. So that's what I've been using for
sometime now. This is of course a single data point and I have not had
the occasion to do try anything with later releases.
Hi Mac,

Thanks for the note, but I'm already using AVLinux on my laptop. I have
three machines here, each running a different distro, and Arch is the
64-bit distribution of choice (the 32-bit others are Ubuntu 10.04 and
AVLinux). 64 Studio was a rock-solid champ of a system until it aged
beyond rejuvenation. Now I want another rock-solid nVidia-friendly
xrun-less 64-bit system, and I'm wondering if it's even possible with
the current 3.x kernels. However, I shall persist. :)

Best,

dp
gene heskett
2011-12-15 16:00:02 UTC
Permalink
Post by Dave Phillips
...I then stumbled on AVLinux. I installed it, fired up Jack and
Ardour...and it just worked. So that's what I've been using for
sometime now. This is of course a single data point and I have not had
the occasion to do try anything with later releases.
Hi Mac,
Thanks for the note, but I'm already using AVLinux on my laptop. I have
three machines here, each running a different distro, and Arch is the
64-bit distribution of choice (the 32-bit others are Ubuntu 10.04 and
AVLinux). 64 Studio was a rock-solid champ of a system until it aged
beyond rejuvenation. Now I want another rock-solid nVidia-friendly
xrun-less 64-bit system, and I'm wondering if it's even possible with
the current 3.x kernels. However, I shall persist. :)
New bee here, to this list, but not to linux, I have been windows free
since RH5.0 in the late '90's.

In my experiences with EMC (electronic Machine control, as in cnc lathes
and milling machines), which when driving stepper motors, needs absolute
low latency and uses the RTAI version kernels to achieve this as the output
loop timing when driving steppers may be as low as 20 microseconds per pass
through the output loop, I've found that the nvidia blob and what you would
call an x-run-less system, are going to be mutually exclusive because the
nvidia blob locks out the IRQ's for extended (sometimes in excess of 200
milliseconds) periods. So even an nvidia card gets driven with the vesa
driver which doesn't do that.

For that reason, I currently have an ATI X-1650 card in that box, using the
linux ati/radeon driver. This combo actually gives me about the same
latency's as the vesa driver does, but with a much more accurate display
drawing. The vesa driver is so slow that the backplot drawing takes
shortcuts when the tool turns a corner, the linux ati/radeon combo does a
much better job in that regard.

And no, I don't own stock in amd/ati. :)

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Somebody ought to cross ball point pens with coat hangers so that the
pens will multiply instead of disappear.
Dave Phillips
2011-12-19 14:12:58 UTC
Permalink
Greetings,

A quick update on the problem. Two things appear to have helped
considerably: I now run the rtirq script to optimize the IRQ
assignments, and I set the sr for my Delta 66 to 48k, the same rate as
JACK. It had been set at 44.1 with JACK running at 48k. Whoops.

A3 is much happier, even without the rt-patched kernel, but I intend to
build and install the 3.0-rt sources anyway.

My thanks to everyone who responded, I appreciate the assistance.

Best,

dp
Robin Gareus
2011-12-19 15:11:42 UTC
Permalink
Hi Dave,
Post by Dave Phillips
Greetings,
A quick update on the problem. Two things appear to have helped
considerably: I now run the rtirq script to optimize the IRQ
assignments, and I set the sr for my Delta 66 to 48k, the same rate as
JACK. It had been set at 44.1 with JACK running at 48k. Whoops.
A3 is much happier, even without the rt-patched kernel
The important parts - regarding low latency audio - of the RT patch have
been in mainline since 2.6.39.
Post by Dave Phillips
but I intend to
build and install the 3.0-rt sources anyway.
While in general this is beneficial, it's much easier to get it wrong
than get it right.

Unless you aim for very low latencies < 2ms or need to have 100%
[software,scheduler] reliability (for on-stage performances) a default
voluntary-preemt kernel with 'threadirq' should be sufficient. YMMV.

Personally I have not yet succeeded to compile a re-usable reliable
3.0.X-rt; Some revisions require nohz option, some others have problems
with suspend/resume and/or power-off. It's a bit of a kludgy situation.

However it is possible to get a reasonably stable desktop:
3.0.6-rt17+ SMP PREEMT x86_64 has an uptime of 68 days here, zero x-runs
since then with jackdmp 1.9.7 @64f/p * 3p/c.

I have not yet tried 3.2-rc5-rt7
Post by Dave Phillips
My thanks to everyone who responded, I appreciate the assistance.
Best,
dp
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user
Dave Phillips
2011-12-19 15:52:12 UTC
Permalink
Post by Robin Gareus
Hi Dave,
On 12/19/2011 03:12 PM, Dave Phillips wrote: ...
Post by Dave Phillips
but I intend to
build and install the 3.0-rt sources anyway.
While in general this is beneficial, it's much easier to get it wrong
than get it right.
Unless you aim for very low latencies< 2ms or need to have 100%
[software,scheduler] reliability (for on-stage performances) a default
voluntary-preemt kernel with 'threadirq' should be sufficient. YMMV.
Hi Robin,

Well, I won't be able to put time into it until next week anyway, so in
the meanwhile I'll continue to test things with some more recording in
A3. I've been editing - but not recording - a fairly complex session
this morning with no xruns.

Thanks for the notes.

Best,

dp

Continue reading on narkive:
Loading...