8 May
2009
8 May
'09
4:37 a.m.
Hi LAU,
Right now, I'm optimizing my system for audio work, and have experienced some
problems.
First, this is my system: Kubuntu 9.04 with 2.6.28-3-rt (noacpi nosmp (the
system freezes w/o nosmp, possible because of the nvidia x-driver)), jack
1.9.2 running on an Athlon64 X2 6400+, 3.2 GHz with 8 GB RAM and a MSI K9N SLI
Platinum MB. The Soundcard is a Delta 1010 from M-Audio. All in all, a decent
Audio HW I believe.
Normally, my DSP load varies from 1 to 2% when the Jack server runs without
other Jack enabled apps. ACPI is enabled on the MB and disabled as a kernel
parameter; but so far, so good.
Lately, I have tried to assign IRQ 9 (occupied by ACPI) to my 1010 card wo.
success (can't assign the PCI port to IRQ 9 in BIOS), it's always shared with
sata_nv, sata_nv and ohci_hcd:usb2 (from cat /proc/interrupts). What I now
tried is to just disable ACPI on the MB (from BIOS) in order to free IRQ9 and
it's now the funny things starts: now, the DSP load is from 0.0004% (very
rare, but typical down to aprox. 2%) and stays mostly up to around 38%!
I have done the usual work in /etc/security/limits.conf, and the indexing work
in /etc/modprobe.d/alsa-base.conf in order to lock the 1010 to hw:1. Jack
priority is 70, frames 64, sample rate is 44100 and periods 2 (latency 2.9 -
earlier, I could reduce to 0.7 ms when needed w/o x-runs).
So what's up here? Why can't i separate the 1010 from the system? The 1010 is
sharing the IRQ with the HDs, that's nothing I want. Why the insane DSP load
when ACPI is off in BIOS?
The outputs of "cat /proc/interrupts" and "lspci" are at the end of
this
posting.
Thanks,
Jostein
------------------------------------------------
Here is my "cat /proc/interrupts"
cat /proc/interrupts CPU0
0: 876748 XT-PIC-XT timer
1: 2 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
5: 257354 XT-PIC-XT sata_nv
7: 2 XT-PIC-XT
8: 1 XT-PIC-XT rtc0
9: 0 XT-PIC-XT acpi
10: 760257 XT-PIC-XT sata_nv, sata_nv, ohci_hcd:usb2, ICE1712
11: 56400 XT-PIC-XT ehci_hcd:usb1, HDA Intel, nvidia
12: 4 XT-PIC-XT i8042
14: 8314 XT-PIC-XT pata_amd
15: 0 XT-PIC-XT pata_amd
2297: 85027 PCI-MSI-edge eth0
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
SPU: 0 Spurious interrupts
ERR: 2
lspci:
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:00.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24]
PCI Multi-Channel I/O Controller (rev 02)
07:00.0 VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev a1)
13 May
13 May
11:06 a.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Friday 08 May 2009 08.36.53 Jostein Chr. Andersen wrote:
...
First, this is my system: Kubuntu 9.04 with
2.6.28-3-rt (noacpi nosmp (the
system freezes w/o nosmp, possible because of the nvidia x-driver)), jack
...
I did the ultimate "hack": I bought an ATI Radeon based card (ASUS EAH3450)
and ripped off the GForce 8400G.
The result: xrun-free latency down to 0.726 ms without any IRQ priority
adjustments. I use my beloved KDE 4 at the same time without any problems so
now I'm very, very happy! I'm not any hurry for optimizing the machine further
(the shared IRQ problem etc), even when it can be much better.
Thanks to you who answered to my first post on this subject.
Jostein
6:50 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Wed, 13 May 2009, Jostein Chr. Andersen wrote:
On Friday 08 May 2009 08.36.53 Jostein Chr. Andersen
wrote:
...
Wow...just for reference, what kind of motherboard/cpu was this? There
are probably a lot of people (like me) that would like to know the
hardware when a success story is achieved. Also, what audio card and
distro?
(Less than a millisecond??) :-O
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
First, this is my system: Kubuntu 9.04 with
2.6.28-3-rt (noacpi nosmp (the
system freezes w/o nosmp, possible because of the nvidia x-driver)), jack
...
I did the ultimate "hack": I bought an ATI Radeon based card (ASUS EAH3450)
and ripped off the GForce 8400G.
The result: xrun-free latency down to 0.726 ms without any IRQ priority
adjustments. I use my beloved KDE 4 at the same time without any problems so
now I'm very, very happy! I'm not any hurry for optimizing the machine further
(the shared IRQ problem etc), even when it can be much better. 
7:06 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Wed, 13 May 2009 15:50:08 -0500 (CDT)
Brent Busby <brent(a)keycorner.org> wrote:
On Wed, 13 May 2009, Jostein Chr. Andersen wrote:
The question is if this is a calculated or real (measured) value.
Consider measuring with jdelay.
Regards,
Philipp
On Friday 08 May 2009 08.36.53 Jostein Chr.
Andersen wrote:
...
Wow...just for reference, what kind of motherboard/cpu was this?
There are probably a lot of people (like me) that would like to know
the hardware when a success story is achieved. Also, what audio card
and distro?
(Less than a millisecond??) :-O
First, this is my system: Kubuntu 9.04 with
2.6.28-3-rt (noacpi
nosmp (the system freezes w/o nosmp, possible because of the
nvidia x-driver)), jack
...
I did the ultimate "hack": I bought an ATI Radeon based card (ASUS
EAH3450) and ripped off the GForce 8400G.
The result: xrun-free latency down to 0.726 ms without any IRQ
priority adjustments. I use my beloved KDE 4 at the same time
without any problems so now I'm very, very happy! I'm not any hurry
for optimizing the machine further (the shared IRQ problem etc),
even when it can be much better.
14 May
14 May
7:05 a.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Wednesday 13 May 2009 23.06.05 hollunder(a)gmx.at wrote:
The question is if this is a calculated or real
(measured) value.
Consider measuring with jdelay.
I'm not sure how to use jdelay (jack_delay), but I started it and connected
jack_delay's out to system playback_in and system capture_1 to jack_delay's in
and then listening to that terrible sound, here is the output:
With latencies 2.9 and according to qjackctl:
capture latency = 64
playback_latency = 128
Signal below threshold...
Signal below threshold...
1.45
and with latency 1.45 according to qjackctl:
capture latency = 32
playback_latency = 64
and with latency 0.726 according to qjackctl:
capture latency = 16
playback_latency = 32
Signal below threshold...
Signal below threshold...
How come that I only get "Signal below threshold... ", is that right and is it
good? If I start up TimeMachine, then the meter shows 5 (pretty high output).
Jostein
7:18 a.m.
New subject: ACPI, HW and Jack issues? "[solved]", correcion
On Thursday 14 May 2009 11.05.56 Jostein Chr. Andersen wrote:
On Wednesday 13 May 2009 23.06.05 hollunder(a)gmx.at
wrote:
> The question is if this is a calculated or real (measured) value.
> Consider measuring with jdelay.
ok, i connected jack_delay's out to jack_delay's in and got this:
With latencies 2.9 and according to qjackctl:
capture latency = 64
playback_latency = 128
64.000 frames 1.451 ms
and with latency 1.45 according to qjackctl:
capture latency = 32
playback_latency = 64
32.000 frames 0.726 ms
and with latency 0.726 according to qjackctl:
capture latency = 16
playback_latency = 32
16.000 frames 0.363 ms
and with latency 0.363 according to qjackctl, now with xruns and unstable
output:
capture latency = 8
playback_latency = 16
8.000 frames 0.181 ms
7.999 frames 0.181 ms
8.000 frames 0.181 ms
8.000 frames 0.181 ms
8.001 frames 0.181 ms
8.000 frames 0.181 ms
8.000 frames 0.181 ms
7.999 frames 0.181 ms
Does this mean that I actually get a sub 1 ms latency when runnung with
latency of 1.45 according to qjackctl?
Jostein
8:02 a.m.
New subject: ACPI, HW and Jack issues? "[solved]"
I', really sorry about the noise, but think I did it right this time:
On Wednesday 13 May 2009 23.06.05 hollunder(a)gmx.at wrote:
...
The question is if this is a calculated or real (measured) value.
Consider measuring with jdelay.
I physically connected a patch cable between the 1010's channel 3 out an in
and then in qjackctrl connected jack_delay's out to system playback_3 and
system capture_3 to jack_delay's in. Now, the picture changed totally:
With latencies 2.9 according to qjackctl:
capture latency = 64
playback_latency = 128
262.197 frames 5.946 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.191 frames 5.945 ms
and with latency 0.726 according to qjackctl:
capture latency = 16
playback_latency = 32
117.187 frames 2.657 ms
117.190 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
But this just mean that latency because the soundcard is at the best 2.7 ms
when sending sound from it's out to it's in and it is better when just
recording, right? And apps that is jack only connected still have 0.4 ms
latency?
Thanks for pointing me to jack_delay.
Jostein
11:52 a.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Thu, 14 May 2009 12:02:34 +0200
"Jostein Chr. Andersen" <jostein(a)vait.se> wrote:
I', really sorry about the noise, but think I did
it right this time:
On Wednesday 13 May 2009 23.06.05 hollunder(a)gmx.at wrote:
...
Yep, that's the way to do it.
I did it wrong at first as well..
The question is if this is a calculated or real (measured) value.
Consider measuring with jdelay.
I physically connected a patch cable between the 1010's channel 3 out
an in and then in qjackctrl connected jack_delay's out to system
playback_3 and system capture_3 to jack_delay's in. Now, the picture
changed totally: With latencies 2.9 according to qjackctl:
capture latency = 64
playback_latency = 128
262.197 frames 5.946 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.191 frames 5.945 ms
and with latency 0.726 according to qjackctl:
capture latency = 16
playback_latency = 32
117.187 frames 2.657 ms
117.190 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
These values look good to me, just remember that the nicest values
won't help you unless you can get them under heavy load without xruns.
Expect worse numbers from your usb device. I have some measurements
from mine and some other people were so kind to provide some as well,
just need to put them together for a comparison some day.
But this just mean that latency because the soundcard
is at the best
2.7 ms when sending sound from it's out to it's in and it is better
when just recording, right?
Yes, this is round-trip latency, just in or just out will be faster
(take half(?) the time).
And apps that is jack only connected
still have 0.4 ms latency?
From which measurement do you conclude that?
Jack itself shouldn't really add latency afaik but I'm no expert.
Thanks for pointing me to jack_delay.
Jostein
You're welcome, it's a really handy tool (if you are interested in
real, not just low, numbers).
Regards,
Philipp
15 May
15 May
1:04 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Thursday 14 May 2009 15.52.10 hollunder(a)gmx.at wrote:
...
When jack_delay's out is connectet to jack_delay's in:
Latency 0.726 according to qjackctl gives:
capture latency = 16
playback_latency = 32
16.000 frames 0.363 ms
Jostein
And apps that
is jack only connected
still have 0.4 ms latency?
From which measurement do you conclude that?
Jack itself shouldn't really add latency afaik but I'm no expert.
4:26 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Fri, 15 May 2009 17:04:10 +0200
"Jostein Chr. Andersen" <jostein(a)vait.se> wrote:
On Thursday 14 May 2009 15.52.10 hollunder(a)gmx.at
wrote:
...
When jack_delay's out is connectet to jack_delay's in:
Latency 0.726 according to qjackctl gives:
capture latency = 16
playback_latency = 32
16.000 frames 0.363 ms
Jostein
playback twice as much as capture, hu?
Where do you see that in qjackctl?
Philipp
And apps
that is jack only connected
still have 0.4 ms latency?
From which measurement do you conclude that?
Jack itself shouldn't really add latency afaik but I'm no expert.
5:35 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Friday 15 May 2009 20.26.26 hollunder(a)gmx.at wrote:
playback twice as much as capture, hu?
Where do you see that in qjackctl?
Down to the right corner in the settings/options box above the OK and Cancel
buttons: there is the latency label and text box with the calculated value.
Jostein
5:42 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Fri, 15 May 2009 21:35:43 +0200
"Jostein Chr. Andersen" <jostein(a)vait.se> wrote:
On Friday 15 May 2009 20.26.26 hollunder(a)gmx.at
wrote:
yep, but I only have one values there, never seen two.
Philipp
playback twice as much as capture, hu?
Where do you see that in qjackctl?
Down to the right corner in the settings/options box above the OK and
Cancel buttons: there is the latency label and text box with the
calculated value.
Jostein
14 May
14 May
5:09 a.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Wednesday 13 May 2009 22.50.08 Brent Busby wrote:
...
Wow...just for reference, what kind of motherboard/cpu
was this? There
are probably a lot of people (like me) that would like to know the
hardware when a success story is achieved. Also, what audio card and
distro?
(Less than a millisecond??) :-O
Yes, less than a millisecond. :-) ..but I still have to send "nosmp" to the
kernel in Grub's menu.lst-file - or the system freezes; I wasn't aware of that
when I wrote to this list yesterday - so it's still a lot of potential for
improvements; just as with the proprietary nvidia driver for my previos GPU,
the proprietary ATI driver don't play nice with the rt-kernel, but I have a
much quicker and stable sustem with the ST GPU. So I guess that it's a problem
with the Ubuntu RT-kernel (2.6.28-3-rt) and possible in combination with some
motherboard issues that I haven't figured out yet.
Anyway, the system is quick and stable even with this quirks, here are the
specs (and some extended info because I'm in the mood for it):
MB: MSI K9N SLI Platinum
CPU: Athlon64 X2 6400+, 3.2 GHz
RAM: 8GB: 2 * Kingston ValueR. DDR2 PC6400 4096MB CL5, Kit w/two
matched ValueRAM 2048MB DDR2 (total of 4 pieces)
GPU: Asus Radeon HD 3450 256MB DDR2, PCI-Express 2.0, DVI, Passive
(that means no fan, making the machine more quiet)
SC: M-Audio DELTA 1010 which is Jack driven and the ALSA driven
MB's card, an Intel HDA, which serves for light monitoring and
ordinary usage purposes.
OS: Kubuntu 9.04 64 bit with 2.6.28-3-rt running and with almost
every music related apps and libraries compiled from scratch.
Jack: In normal use, the setting are: Frames: 64, sample rate 44100,
periods: 2 which gives 2.9 ms of latency. I normally reduce
the frames down to 16 (0.726 ms) when i do recording and up
to 512 (23.2 ms) and rarely even up to 1024 (46.4 ms) when
mixing. I have experienced xruns if the latency is to high,
perhaps some apps or HW are impatience? :-)
I suspect that the MSI K9N is not an ideal solution for Audio, but that the
power of CPU and the system at large makes everything good anyway.
The main apps are Ardour, Rosegarden and Linuxsampler (loaded with 4-5 GB of
sounds, NDK, pianos, brass and bass) and occasionally zynaddsubfx and
FluidSynth (Qsynth).
I use to do files in 44100 and 24 bit. I believe that 48000 is not (very)
audible, in order to be audible it should be 96000 which I'm not ready to use
as a standard yet. I always record samples and synths and any sequencer
related stuff into Ardour before mixing, freeing resources to plugins.
Speaking of plugins: I really love the Calf plugins, especially the compressor
for drums, awesome! For Guitar work, I use a POD or micing up amplifiers with
SM 57's. IMO the POD sounds great in the mix, but the compressor really sucks,
so I have a Marshall ED-1 first in the chain when using guitars with low
output SC. I use QtPod for controlling the POD from the computer. Keyboard
controller is an Edirol PCR 800.
The average or sane user will probably use a ready music distro or additions
like CCRMA with the apps from the repository. I use Kubuntu because I like it
and mainly use Ubuntu (both desktop and servers) for work. This makes my life
easier. I also use a similar setup on my Laptop, but with a Edirol UM-2ex
interface for MIDI and a M-Audio MobilePRE USB audio interface.
I hope that this info can be of some value for someone that wonders where to
go or just are interested.
Jostein
3:21 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Thu, 14 May 2009, Jostein Chr. Andersen wrote:
Yes, less than a millisecond. :-) ..but I still have
to send "nosmp" to the
kernel in Grub's menu.lst-file - or the system freezes; I wasn't aware of that
when I wrote to this list yesterday - so it's still a lot of potential for
improvements;
Hmm...seems like I've been seeing that a lot lately -- people who are
getting low latency to work, at the expense of SMP. This is troubling
for me, because I was planning on soon finally upgrading my Athlon XP
based system to an AMD quad core. Is the realtime kernel always badly
behaved on a multi-CPU system with SMP enabled? That could be bad,
considering that there almost isn't any other kind of PC these days.
just as with the proprietary nvidia driver for my
previos GPU,
the proprietary ATI driver don't play nice with the rt-kernel, but I have a
much quicker and stable sustem with the ST GPU. So I guess that it's a problem
with the Ubuntu RT-kernel (2.6.28-3-rt) and possible in combination with some
motherboard issues that I haven't figured out yet.
I'm planning on running a recent Radeon with the new free ATI driver
(called 'radeonhd?'). Is that going to be a problem?
OS: Kubuntu 9.04 64 bit with 2.6.28-3-rt running and
with almost
every music related apps and libraries compiled from scratch.
You probably saved yourself a lot of headache there. From what I've
been hearing, the distros have been dropping the ball on the A/V
packages lately. (I hear 64Studio is nice though.) Compiling your own
seems to solve all kinds of problems. Besides, 90% of what I expect
from a distro is easy security updates. But how often have you seen a
security exploit in something like Rosegarden or Ardour that somebody
could honestly use to hack your machine?
For stuff like A/V software, why NOT do local compiles? :)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
15 May
15 May
6:28 a.m.
New subject: [LAU] ACPI, HW and Jack issues? "[solved]"
On Thu, 14 May 2009 12:20:58 -0500 (CDT), Brent Busby <brent(a)keycorner.org>
wrote:
Hi !
This, I can reply to :)
Now that we start to see some working free drivers for ATI cards, one
should use the name fglrx when referring to the proprietary drivers. The
fglrx drivers are the ones that have issues with the -rt kernels. You
should be safe with the xf86-video-radeonhd or xf86-video-ati driver (yes,
even with a radeonHD card, xf86-video-ati will work). Although remember
that on r6xx and r7xx chipsets, both drivers are far from bug free
(although it does work for me for everyday use).
Cheers,
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
On Thu, 14 May 2009, Jostein Chr. Andersen wrote:
> just as with the proprietary nvidia driver for my previos GPU,
> the proprietary ATI driver don't play nice with the rt-kernel, but I
have
a
much quicker and stable sustem with the ST GPU. So I guess that it's a
problem
with the Ubuntu RT-kernel (2.6.28-3-rt) and possible in combination with
some
motherboard issues that I haven't figured out yet.
I'm planning on running a recent Radeon with the new free ATI driver
(called 'radeonhd?'). Is that going to be a problem?
1:19 p.m.
New subject: ACPI, HW and Jack issues? "[solved]"
On Thursday 14 May 2009 19.20.58 Brent Busby wrote:
On Thu, 14 May 2009, Jostein Chr. Andersen wrote:
I consider to go back to a minimal Ubuntu 8.04 and install it's rt-kernel only
and from there install anything I need from source. The 8.04 was rock stable
in the beginning, but I suspect that the RT-kernel was messed up in a later
upgrade. If I don't run a apt-get upgrade ever when I have that system, then
it will be production ready again. The security is not a big issue, because
the network is disabled (except when I have to be online with it).
Jostein
Yes, less than a millisecond. :-) ..but I still
have to send "nosmp" to
the kernel in Grub's menu.lst-file - or the system freezes; I wasn't
aware of that when I wrote to this list yesterday - so it's still a lot
of potential for improvements;
Hmm...seems like I've been seeing that a lot lately -- people who are
getting low latency to work, at the expense of SMP. This is troubling
for me, because I was planning on soon finally upgrading my Athlon XP
based system to an AMD quad core. Is the realtime kernel always badly
behaved on a multi-CPU system with SMP enabled? That could be bad,
considering that there almost isn't any other kind of PC these days.
5673
days inactive
5680
days old
linux-audio-user@lists.linuxaudio.org
15 comments
4 participants
participants (4)
-
Brent Busby -
hollunder＠gmx.at -
Jostein Chr. Andersen -
MarcO'Chapeau