Requirements / Benchmarks

Community Ideas for Ardour
#1

Hi Ardour land!

I have just been pretty badly hit by a severe case of unreasonable expectations - in fact it almost split my band up and so I’m wanting to ensure nobody else goes through the same as I know how we can prevent a lot of upset, disappointed users and that is by including a ‘Requirements’ section on the Downloads page on ardour.org which will ideally also include (a link to) some benchmarks of a recent Ardour 2 release running on various classes of hardware at different sample rates.

We as a community should amass some benchmarks for at least three different classes of hardware ie

Minimum Spec - Something like a P4 class w/ 1GB RAM

Mid Rage - Maybe a Core 2 duo system, 2GB RAM

High End - 4 or more cores, 4GB+ RAM w/ fast SCSI drives

For each class of machine the benchmarks will list approx. how many tracks, with and without the use of plugins, the hardware should be able to handle at 44.1, 48, 96 and 192Khz. I think most people use 48Khz, the numbers won’t be wildly different between 48Khz and 44.1Khz and few use 192Khz so if it only lists expected results for 48 and 96 I think that’d be good enough for people to gauge what they can expect before they encounter difficulties.

I’ll help out with this of course but I’d like to hear people thoughts on what and how many plugins we should use in these benchmarks, best methods for conducting the tests etc. before we begin.

It might also be a good idea to link to or recommended audio hardware as part of this ‘Requirements’ section ie list the cards fully supported by FFADO (which is only a few) and also list the recommended ALSA PCI cards for use by (semi)pro users- again its only a small number of cards which would be up for consideration and it would spare them trawling the ALSA site or LAU/LAD postings.

#2

Hi,

could you elaborate on your experience? Was this some issue with Ardour?

Best
Benjamin

#3

You do realize that what you are asking to do is pretty much impossible to do.

You are asking for a set of benchmarks with an unlimited amount of variables. Literally. It is hard enough to get one with a limited set of variables, but with Linux you really are dealing with an unlimited set, especially when you start throwing in plug in combinations.

As the previous poster mentioned, it might be better to detail exactly what the problems you had were and your own story for other people(And maybe get suggestions on what to improve if anything). It could be useful to have a section of the forums dedicated to this I could see, but trying to do official benchmarks and in the level of detail that you are looking for with that many variables, is just impossible.

In as far as managing expectations in general, this is a large part of my job as a consultant and sound designer/engineer. If expectations get out of control, it means I haven’t done my job right, whether it be because of lack of knowledge that I should have fixed with testing early on, or via communication(2/3 of a live engineers job and I would wager a good portion of the recording engineer’s job as well), etc. Reports of working and not working configurations certainly do help with this, but they are no substitute for hands on experience.

In as far as requirements specifically, the requirements for running Ardour are pretty minimal by today’s standards. I know people running it on netbooks and the like, I ran it successfully on the first computer I ever bought and built from scratch, which was a 500MHz AMD k7 with minimal RAM. But the catch is what I did on such a setup was also minimal compared to what I am doing now on a dual core laptop with 2 gigs or ram, which is even now still a fairly modest setup. The requirements for tracking a live show(40 tracks to over a hundred), especially at the range that some of us do with Ardour, are VERY different from the requirements for mixing an album that consists of 32 tracks all with plugins, most with multiple, and many busses with plugins on top of that. One could be done on a computer with very minimal processing power so long as the HD is fast enough, the other however might not need as fast a HD setup, especially if you are tracking each instrument individually, but the amount of processing needed would increase. Or throw in live mixing on Ardour which require a significant amount of processing and very precise and tuned setups complete with RT patched kernels, tracking at the same time would add in the same HD access requirements as tracking a live show on top of all of that.

So the point is writing a ‘requirements’ section for Ardour is not very simple as the use cases vary wildly which changes the requirements as well. I would certainly be against duplicating information available and more likely to be kept up to date on other sites though(FFADO and ALSA).

 Seablade
#4

Seablade:

Yep, yep- well aware of all your concerns and the infinite combination of distros, kernels and usage requirements but all this does not make my idea impossible or invalid. Those people (if any) who are willing to do some benchmarking would just need to give a detailed listing of their OS and hardware specifics and jobsagoodun. Its unreasonable for anyone to expect to see results for their exact system but if everyone is conducting the same tests with the same sound files and plugin settings, we have a good spread of hardware and software combos and people can reference the test machines spec in comparison to theirs and get a ballpark idea of what to expect from their hardware then we’ll have a very useful resource.

WRT the plugins- we’d just have to pick one or two popular plugins that are reasonably CPU intensive and standardise on the settings.

As you say, this is all about managing expectations and reducing the damage that setting these incorrectly can have. In our case, my core2 duo laptop died shortly after we acquired our Focusrite Pro 26 hence we were forced into hobbling along with an old P4 HT desktop we had lying around. Its got near 3GB RAM and a decent size if very average speed SATA drive and I did thoroughly warn my band this kit was very unlikely to handle a full session @ 24bit 96Khz but they wanted to take the risk and record at that rate anyway. I said it was very likely not to work out and now we’re stuck with a session that kills JACK as soon as you add a plugin to a track (apparently- I wasn’t in ‘the studio’ last night) so its either buy new hardware (which none of us can afford right now), attempt session samplerate conversion (wish us luck with that one) or just write it off as a time and labour expensive experiment which is how I’d like to see it but not everybody agrees.

EDIT

btw I’d say like to add that Ardour got a lot further and performed much better than I expected on ye olde box. I’m not sure of the exact track count but I’m sure its managed about 20 or so tracks @ 24/96 w/o plugins before JACK started cutting out on us. Restarting JACK also means having to restart ffado-dbus-server, ffado-mixer and Ardour to get back up and running which is a chore so I’m hoping they’re up for giving the setup another chance at a much more realistic 48Khz.

#5

If you only have a single HD in that machine, that is likely your biggest bottleneck. Simply playing back and recording 24 tracks even at 96k should be but so taxing, and you should be able to get a light plugin load on that without to much problem. This of course applies to ANY DAW, as having your OS and audio data on the same drive kills throughput of that drive, and especially with older drives this can kill any performance playing back or recording. Get your session on a separate drive if at all possible.

 Seablade
#6

Hi danboid,

for your special case: Which buffer size does jack use? How high is your DSP load? I would try to increase the buffer size. I did quite a big setup back in 2008 (I think with about 20-25 tracks) with a 1,4 GHz AMD, of course I couldn’t use hundreds of plugins so I rather used busses and had to mixdown some effects.

Best
Benjamin

#7

Thanks for your tips guys!

Seablade:

Good point on the HD- yes it just has the one drive ATM but I’ve got another we can use. I’m amazed I didn’t think of that as it does seem a very obvious thing to do when you mention it.

Ben + Paul:

Not sure what the jack buffer is set to right now - looking at the JACK FAQ (which Paul says is the definitive source of info on these issues) it doesn’t seem to go into how to gauge the optimal size and number of buffers so I presume experimentation is key here. Might be a good addition eh Mr. las?

#8

@danboid

Well I can answer some things, yes a bit of experimentation is in order, however general rule of thumb is that unless you are on a USB device(unsure about firewire) 2 periods/buffer is the norm and usually the best setting. Then, unless you are doing something that specifically requires low latency, using the largest period size you can is the best option to ensure smooth performance, but typically anything 512 and up should be fine. For the record I am often using 2048 unless I am using it for live mixing or processing for some reason, then I will go with as small as I can as low latency is required in those specific cases.

What I do need to do for this though is compile all the information collected thus far on the latency compensation settings in Jack that Ardour uses into an article on the tech ref, but have not had time to do much of anything lately. I do recommend searching these forums for that information as some good information can be found here thanks to other posters.

  Seablade