Performance question

Hello, this is my first post here!

Is there a rough guide (yes, I know it would have to be very rough) for how much processing power, memory and disk speed is needed for an Ardour system of a given size. (no. of channels, typical plugins etc.)

More specifically, I’ve just set up a Delta 1010 on a system I bought for audio recording several years ago, but for various reasons never got around to using for that. Now I need advice on whether to upgrade it before starting on an 8 track recording project.

Here’s what I’ve got:
AMD Single core 1.8 GHz CPU
120GB IDE HD of which about 56GB are available for Studio64
64Studio downloaded about 2 weeks ago

I have a project coming up which will involve recording 8 channels together and then some mixing.
I hope I won’t have to do overdubs and punch-in repairs so I believe low latency is not a priority.
48kHz/24 bit input (could be 44.1k), 32 bit processing.

The real question is: should I upgrade now or will my system cope?
New hardware might be something like:
Athlon dual core 3GHz
2GB DDR memory
SATA disk

In an attempt to answer my own question I plan to try some test recordings on 8 channels; what should I look for when testing? Bear in mind I’m quite new to Ardour and Jack (but not to Linux, recording or how digital audio works) so there may be some obvious tools that I’m not familiar with.

Grateful for any ideas

anahata: Your test recording should give you a really good idea of what you’ll be able to do in a real-world scenario, but I can tell you that I’ve done a similar setup recently that worked great. Here was my setup:

Pentium 4 2ghz
1 20GB IDE HD for an Ubuntu system
1 40GB IDE HD for recording (mounted with the “noatime” option)
A Delta 1010LT

I was able to record on all 8 channels as well as spdif in (10 in channels total), using 6 channels out (1 stereo control room, 4 mono headphone). The system had no problems running with a period size of 128 (approx. 6ms latency), and although I don’t remember exactly what kind of CPU usage I was seeing, the system was nowhere near choked; I had a reverb bus and a compression bus set up for the singer. The system I was using was running fluxbox for a window manager with compositing turned on, which uses less RAM than the standard Gnome desktop, but I probably could have gotten even better performance with compositing off, and to be honest I’m sure everything would have worked in that configuration even with a full Gnome desktop with Desktop Effects on. In fact, the only reason I had been using fluxbox in the first place was because the system HD was from an older machine. Not only did this machine work well during recording at fairly low latency, I’ve used the same setup at approx. 3ms latency for two separate live shows, to both record the performance and run the live mix for a 3 piece band, and it worked fine for that too. I can’t comment on 64studio, but it should be similar, however, I should mention that I did try all the pci slots in the computer to make sure the 1010 got its own IRQ in the BIOS before I even installed a hard drive, and once the system was installed, I wrote a startup script to change the pci latency of all devices to as low as they would go, apart from the sound card, which I set as high as it would go. Read the following page for more info: I was also using a realtime kernel.

anahata: That old single core system should be fine for an 8 track recording project. I’ve been using a similar system and been having good results.

My setup:
Athlon XP2600
60GB system drive
500GB Data drive
2 x Delta 1010
Studio64 2.1
Ardour 2.8.11
Jack 1.9.5

With this setup I’ve easily done 16 in and 20 out and managed some pretty high track counts running at 48k with a period size of 128.

You may want to invest in a new HD for recording onto though. Separate data drives are always a good thing and the newer drives are faster which definitely helps performance.

Good luck


Thanks for your replies. It looks as if I should be fine.

I’ll do some tests and screw the latency down until I start getting xruns, and then I should have some idea of how much margin I’ve got.

Does using “top” also give me a useful measure of CPU usage for this purpose?

I’ve just remembered that the HD is in fact SATA so it’s bettter than I first thought.
As the existing HD also has a Windows partition on it and a lot of files I need to keep, adding a second HD and using it only for data should be easy and work well.

macinnisrr: I’m also considering using 10 inputs with the SP/DIF as I have a Lexicon MPX200 reverb unit that makes a handy 2-channel A-D converter and I do have a couple channels more mic preamps. Whether I need them depends on how good a drum sound I can get with two mics…

I’ve been trying to make sense of the tricks people use to avoid xruns.
I can’t see or check things immediately as I’m at work now and the system in question is at home, but I want to know what to try when I get home.

I assume my 64studio kernel is set up with all the real time tweaks possible and I don’t need to change anything there.

a startup script to change the pci latency of all devices to as low as they would go, apart from the sound card, which I set as high as it would go.

When I reduced latency by setting smaller buffers in Jack, I got xruns that clearly coincided with switching windows on my display, e.g. clicking on Ardour’s main window and then the mixer window, then the Jack server messages window.

It does looks as if the most likely culprit is PCI latency on my video card.
I’ll have to try that…
It’s a PCI Express card - does that system still have latency figures that can be adjusted with setpci?

I think there’s only one PCI slot for my M-Audio card, so I can’t change the IRQ by moving it around, as suggested in documents elsewhere. I was trying to make sense of PCI IRQs last night but didn’t get anywhere.

I’m ordering a new HD drive.
Samsung Spinpoint 500Gb 7200 rpm, ext2 mounted -noatime can’t do any harm.


Maybe you like to try the rtirq.conf script, it allows you to attribute IRQs

at the end of the page, I think instructions (README) are inside the .tar

I could be wrong, but isn’t it better to format disk as ext3 ? And to speed up the process, you can have everything on disk one, but all sounds you record on disk two.

I seem to have rtirq installed in /etc/init.d already. I’m not sure I know how I should change its configuration.
If it’s any help, /proc/interrupts looks like this:

0: 246 IO-APIC-edge timer
1: 1097 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 4 IO-APIC-edge i8042
14: 7374 IO-APIC-edge ide0
19: 0 IO-APIC-fasteoi ICE1712
20: 8935 IO-APIC-fasteoi libata
21: 85288 IO-APIC-fasteoi eth0
22: 2 IO-APIC-fasteoi ehci_hcd:usb2
23: 5118 IO-APIC-fasteoi ohci_hcd:usb1

ICE1712 is the Delta 1010
I don’t know whether that’s good or bad, nor how to change it.

AIUI ext3 is safer because of journalling, but ext2 is faster for the same reason - or doesn’t it make enough difference to matter?
And yes, the plan is to simply add the new HD and use it for data.
I now find I’m getting xruns on disk accesses, even at quite long latencies.

Do you run Jack with real-time checked?
See , the “Real-time scheduling” section at the beginning.

Do you run Jack with real-time checked?
It was, last time I looked!
The link was worth a look - a couple of things to check, but I expect the 64studio distribution has taken care of that.

also, please keep in mind that in current versions of JACK, realtime scheduling is the default and does not need to be requested.


for rtirq, and priorities to give to soundcard, jack, etc…

It all checks out. I ran the quickscan utility from and adjusted everything I could.

Something I have noticed:
Ardour creates xrun markers, but Jack’s Status window does not show any xruns.
Are there two types of xruns?
Also I am getting a bit confused about when jackd actually restarts…

OK - problem is sort-of fixed.
When I started Ardour, it started up jackd by itself, WITHOUT the -R switch.
If I start jackd from the command line with -R I now get good performance - 8 channels recording at 1.3ms latency.

The settings shown in qjackctl don’t seem to have anything to do with the running jackd.

What I really want to know now is how Ardour starts jackd if it’s isn’t already running - i.e. where do I edit the command line it uses for jackd. Because It seems I can do without qjackctl, especially as it’s confusing me.

Also I’m not sure which application is using ~/.jackdrc

If you start Ardour without having started jack, either through qjackctl or a manually started jackd command, you get an “Audio Setup” tab in the starting window. In the “Device” and “Options” tabs there you can set the values you want.

And if you want to record a live session you don’t necessarily have to use the lowest latency setting your hardware can cope with. To be on the safe side, with regards to xruns, you should set it up way higher.

I think qjackctl uses ~/.jackdrc

Thanks - yes, after posting I found the XML file ~/.ardour2/ardour.rc where those settings are stored, and then found the “Audio Setup” Panel which is obviously the proper place to set that file’s contents…

Point taken about live sessions, but it’s a new system and I wanted to know what its capabilities were and make sure I had the right settings. I now know that I don’t have to rush out and buy faster hardware, though I had still better see how many plugins I can run without breaking it.

Part of the problem (which I haven’t yet investigated) is that when I click the start button in Qjackctl the jackd server starts and immediately stops with an error. That’s why the settings shown in qjackctl are not the ones being used by jackd - I was running jackd on Ardour’s settings.

Happy now :slight_smile:

Depending on the error, you either have already started a jack session or have faulty settings in qjackctl.

Faulty settings, it seems.
But I’m not bothered now because starting jack from Ardour is all I need at the moment.