Ardour’s System Requirements document is a bit out of date. While it remains possible to run ardour2 in less than 512MB of ram, it would be good if people that are actually doing that could explain how they did it!
On the flip side, some are using ardour and - simultaneously - a slew of other programs like rosegarden, linuxsampler, sooperlooper, hydrogen - the list is nearly endless - and it would be good to know the resource requirements for your specific configuration, too.
On my laptop:
(I run ardour2 on two platforms, both x86_64, running 64 bit.) On the 1.8ghz x86_64 (single core) laptop, I started off on the low end, trying to get low latency out of the onboard audio card, and trying to run ardour2 + rosegarden + linuxsampler in 512MB of ram, at 48khz. More fool me!
I could get two out of three of those programs to run well: if I killed off the gnome window manager (using evilwm or fluxbox instead) - or ran ardour2 remote over client/server X11 to my aging mac, but I could never quite get all 3 to work well at the same time.
Upgrading the laptop hard disk to 7200RPM got me to where I could do 4 tracks pretty reliably, at 5.6ms latency, with all 3 programs running. Ardour2 relies on the OS being able to buffer at least some disk I/O in RAM and there was just no ram to spare (I always had at least 300MB out on swap). Using an external firewire drive for ardour helped the swapping problem.
I bit the bullet and spent 60 bucks on another 512MB ram (and 800 on a lovely RME-audio multiface)
What a difference! For two programs at a time, I got my latency down to 2.7ms at 96khz, and I could run the gnome window manager again, as well as a few other programs, and I could reliably record 4+ stereo tracks at that resolution. Everything was a joy to use. I could even run hydrogen on top of the other 3 programs so long as I moved the latency back some.
(This was on either sound card).
Naturally, the RME-audio card spawned delusions of 24 track recording - and spawned the idea of me moving up to 96khz… I sometimes wish I’d stayed at 44.1…
But - worse - I then blew my memory requirements out the window by purchasing the really wonderful “bardstown bosendorfer” sample for linuxsampler. That sample library is 2.2GB! in size, and even though linuxsampler streams it, it’s still pretty brutal on your disk I/O - so I added another external firewire drive just for samples.
I got this to more or less work well, but for recording rosegarden + linuxsampler + ardour2 I ended up moving back to 10ms latency to get totally xrun free recordings. Typically for hydrogen, I’d create the drum track first, then stick it into rosegarden for playback, treating the compositional process as more of a “rendering” pipeline. I’d knock latency back to 2.7 ms and just wail on rosegarden + linuxsampler - then “render” the results at 10ms into ardour.
(somewhere in here I started working on performance tuning ardour2)
I don’t think a “saner” user than I would have many problems mixing and matching 3-4 audio programs at the same time in 1GB of ram - it’s just my love for this huge piano sample that hurts me and that’s obviously not an ardour issue. (but it hurts sooo goood!) 32 bit users would have even less problems. Still, you may have to make some compromises here and there to get good quality from your final output.
Some notes to make clear from this:
I got an enormous improvement by going to 1GB of ram - from 512 - doubling both my track count and my sample rate - and dropping my typical xrun count enormously.
External drives helped for each disk I/O bound application (separate drives for linuxsampler, ardour’s data, and the OS)
Having more capability meant that I ended up finding creative ways to use up all that capability and more. 
Most of this experimentation was done prior to Linux kernel 2.6.14-rt, and prior to ardour2-beta8. I’ll have some updates on what it can do now on a message yet to come.
This laptop is only a single core. It’s 3 years old.
on to my production studio system in the next message…
The requirements page is now updated. The lower limit on the page is now a 400mhz Pentium or equivalent and 256MB of memory. I am very interested in user experiences on such systems and especially on even more limited platforms.
My temporary recording box has an Athlon64 3700+, nForce4 Ultra, 1GB DDR400, a 320GB SATA-150 disk (soon to be mirrored I hope), and a Delta 1010LT. I had thought that dumping multiple 96k/24bit/stereo tracks into one disk would create problems, but it kept up just fine… turns out the CPU is my enemy. I’ve been using beyond-sources and recently switched to 2.6.19-rt6. I run Gentoo unstable ~x86, pure 32-bit with gcc-4.1.2 and it’s also my desktop.
I’ve managed to create a project with so many LADSPA plugins that ardour uses 40-50% of the CPU when stopped and 100% when playing-- without audio dropouts. That includes 6x TAP Reverberator, 2x TAP Stereo Echo, 1x Echo Delay Line, 1x Dyson Compressor, 1x 4-Band Parametric EQ, 1x TAP Equalizer/BW, 1x TAP Dynamics, and 1x Gate. That doesn’t include the 3 other plugins that are bypassed, and I’m not sure if they’re truly deactivated or simply silenced and still using CPU. Anyone?
Then, when exporting a WAV… it runs for about the same time as the song is long, matching the 100% CPU usage when playing in realtime. I cut it pretty close there… but once the process completes, it basically freezes the machine solid as the audio comes back to life and all those plugins fire up. At that point, the only thing that seems to work is Alt+SysRq+B for an instant reboot, or the physical pushbutton that does the same thing. I finally saw the option ‘stop plugins with transport’ or similar, mean to try it next time. And that’s all at ‘only’ 48kHz because it predates the Delta card’s arrival.
Then the WAV was always not quite written out, therefore corrupt and refused by K3B. I used sox to convert it back to itself and then all was fine-- just needed a header, I guess.
So as for external apps… I can pile on the usual, adding ZynAddSubFX and QSynth (really fluidsynth) and syncing to Rosegarden or Hydrogen. I’ve recorded from fst-hosted VSTi several times, but it knocks JACK off balance on exiting, so I avoid it these days… can’t wait for instrument plugins.
But uber-cool was finally seeing Reason 3 work in WINE, after years of wishful thinking. I was able to record the default rack’s demo song, through JACK, right in ardour-- but ANY other activity would cause it to skip and stutter quite a bit. It was mostly X activity, especially the Reason window… I had to minimize it to get it to play smoothly at all. I tried giving the WM (fluxbox and KDE at different times) the control instead of self-managed windows, then it wouldn’t finish loading. I set a virtual desktop but then I could only play smoothly if I dropped Reason’s output samplerate from 96kHz to 48kHz. Ardour’s own activity was more than enough to ruin the incoming sound… not its fault, though. And Reason’s output buffer won’t get any bigger Maybe I need to increase JACK’s… it’s been set at 128 frames/period.
Most of that Reason testing was in a nearly-empty 96kHz project with a few long regions, and nothing else loaded for audio. I tried both the closed binary nVidia drivers and open source ones, it didn’t make any noticeable difference.
That’s why this is the temporary recording box… but there’s still tweaking to do. I’m only getting started with the pro-audio overlay from several days ago. WINE- even from the pro-audio kit- may be RT-hostile, as it was when I tried to launch Reason with schedtool -F… Hey, I had to know 
I hope that’s good news for someone… a few people over the years said they were were only stuck in Windows because of Reason, pun definitely intended.
1.5Ghz Athlon XP 2100 (or something like that). 1GB RAM. Cheapo VIA mobo from 2003. M-audio Delta 1010-LT. 80 gig IDE disk.
I haven’t done any project over 4 tracks at once, so I definitely haven’t tested the disk I/O limits. The CPU is alright for most plugins in the time domain. Frequency domain stuff is rough. I just did my first video sync test tonight and synced playback with the internal video card eats up lots of CPU just to play back a 320x240 video window.
Limitations, yes but very functional. FWIW, Debian stable with a ardour_vst compile of the 2.0 SVN code.
If I find some time this weekend I might try to get it installed on a Via C3 800 MHz with 384 PC100 ram (onboard video with shared ram). But I don’t know what I should use as soundcard for that. I could transplant a rme 96/8 for some time.
My production box is running FC6, is a dual opteron, 1.6ghz, with 3GB of ram and a terabyte of striped and mirrored storage, spread across 4 sata drives, and I have two usb drives as well as a bunch of usb devices attached. This machine is also using the wonderful RME-audio multiface + a 8 track presonus digimax FS - giving me 16 tracks of very clean 44 or 48 khz audio, or 12 tracks of 96. It has a cheezy - but rock stable - 19 dollar matrox G450 card in it.
I started off with a gigabyte of ram, and in the early days of Linux RT (prior to about 2.6.17-rt8) the dual processor code was very unstable. Now that I use ingo molnar’s yum repository for FC6 and we’re up around 2.6.20-rt8 - the box has been quite stable, with only the occasional kernel hiccough. I also bit the bullet and added 2GB more ram recently.
Advantages over my laptop: capable of running vastly more programs at once with no effect on the recording quality. Mixdowns seem to go faster. Everything is much better. I think my next machine will have 8GB of ram so my sampler can store everything in ram. I worry about the possible effects on the PCI bus mapping this will cause - and look forward to fixing them. I worry that the PCI bus will be obsolete before rme gets around to putting out a PCIe card for the multiface, too.
I recompiled linuxsampler to buffer far more data and allow twice the voices (128). Running with a low period size still causes some xruns but 256 samples/period at 96khz works well.
I can typically record 12 tracks of 96khz data at once, but if I do overdubs, the upper limit seems to be around 10, before I have to bounce a mix of 3-4 tracks down to 1 (and then overdub). CPU isn’t the problem here, it’s disk.
Most of my issues with the higher resolution seem to crop up with disk I/O, particularlly in fast forwarding or reversing audio for lots of tracks. As a result I experimented a bit with striping and mirroring. Stripes of various sizes seemed to do little good, and mirroring worked as good or better than striping. Looking at the disk I/O, I seem to peak at about 21MB/sec of disk I/O - get as high as 30MB/sec - and then this machine hits a wall. Judging from some benchmarks I’ve seen, perhaps it’s because command queuing is not supported on this sata controller. Some tests with a UDMA drive show it outperforming the 4 disk sata stripe! Or, perhaps, I’m saturating a goodly part of the PCI bus. Either way, a more modern machine would probably do better on disk I/O than mine.
(if you have a big project that does lots of disk I/O I’d love to know what iostat 10 100 reports for your typical blocks/sec)
Although 96khz sounded great, I’m now down to using that just for environmental recordings, and editing the older stuff. 44.1 - well, the sky seems to be the limit for channels, plugins all work better than at 96k, and I’ve yet to have to bounce tracks on it, but I suppose that day will come.
This machine is also 3 years old. For comparison, it takes about 20 minutes to compile ardour on it, when a modern core duo can do the same build in under 7 minutes.
I have occasionally run jackdmp on the machine, but I don’t think my graph(s) are typically parallelized enough to see much difference in the overall performance.
After doing a ton of oprofiling, I got ardour up to well over 120 simultaneous channels and quite a few plugins - those patches are in rc1 and one more went into post rc2 svn. I look forward to wringing even more performance out of the latest and greatest hardware if I could just convince Intel or AMD to send me a quad core…
In my queue of things to do for ardour post 2.0:
Hard look at cache contention issues in smp machines
SSE reverse-the-buffer routine (a preliminary experiment showed a 6x potential speedup)
SSE read_peaks - this ought to speed up startup some
serious oprofiling of linux system calls. Currently, for a typical ardour setup, linux system calls account for 25% of the run time nowadays (and the top 5 ardour routines are all SSEd) Hopefully there are a few system calls we can optimize out.
Snappier gui stuff (some patches are already in the surfaces branch)
Multi-display support
This is in addition to a completely rewritten surfaces subsystem for the tranzport and alphatrack. (start at that is in the surfaces branch)
I’d like to take a harder look at the disk I/O subsystem as well. Perhaps threading this will improve matters even more for high end situations.
On top of that - if my summer wasn’t already full enough - plugins start dominating the runtime pretty quickly at this point. Many plugins could use a thorough SSEing. I’ve got most of a SSE2 comb_run done (the core bottleneck in many a tap and swh plugin) but it looks like SSE3 would help it more with a horizontal add. We’ll see what happens.
While not really a small system, by todays standards this is about entry level (Except for the RAM and soundcard).
I had an athlon 3500+ (older core only supports SSE1) with 1 Gb of RAM (Corsair XTC 2-2-2-5 latency timings) running ardour until fairly recently. It was running with a Delta 1010
Running 32bit gentoo with rt-kernel on Fluxbox, with follow-playhead and draw waveforms features turned off.
I was able to record 8 channels simultaneously with another 12 tracks playing back with at least 2 plugins on each existing track(valve simulation, reverb, compressors). That was possible at 2.9 ms latency, CPU load was around 40% User memory at around 256MB.
Oh yeah and that was synced with Jack to MusE which was also driving external sequencers…
I’m in the process of building my new system (Core2 Conroe E6600, 2Gb OCZ enhanced Latency RAM) and have just got over issues with kernel compatibility (Gigabyte DS-4 m/b… it’s too new… kernel not quite stable with it yet - well the onboard NIC anyway)
Anyway, I should have some test results on that within a week or so, but I expect it will blitz.
cheers
Allan
Allan K
sonofzev
Littlewolf Music
Melbourne Australia