No, I don't run ardour, sorry, but generally speaking the only benefit to loading a program from ram (be it tmpfs or a ramdisk) is faster (as in near-instantaneous) start up times.

I'd say look elsewhere for a solution, for one thing, are you using a realtime patched kernel?
(I know very little about this, but I do know it's recommended for audio work like you'd usually do with ardour).

What's your audio setup on linux like, anyway?
I mean what hardware, drivers, and jack setup (which I believe is recommended for ardour, if not mandatory).

And if you don't mind me asking, what are you actually using ardour for?
It's a very high grade app, but overkill for what most people need_________________"You have to invite me in"

I think my sampling rate in qjackctl might have been the culprit. I have two Mackie Onyx mixers with firewire and they are capable of 92khz. I had jack set for 48. I just turned it down to 44.1 and have not gotten an xrun in the amount of time it normally takes at least one to appear. We'll see, though.

Don't mind your asking at all.

I'm a full-time musician who is fed up with Windows. It works, and it works well, but I have to jump through some hoops to turn on my equipment, sometimes more than once. Under my setup in Gentoo, I can just turn it on and go (and now hopefully I've nabbed the xruns problem. I don't mind 44.1).

I do use rt-sources, and I've had a little gracious assistance from Pappy (he's on these forums if you're not familiar with his name) tweaking the kernel. I'm trying to get set up to use Ardour for my final mixing and mastering processing. There are other programs, but none as full-featured as Ardour that I'm happy with. For MIDI, obviously, I need to look elsewhere. I've heard, though, that Ardour plans to implement full MIDI control in version 3.

You can check out my work, if you'd like, through the links in my sig. I'm REALLY hoping to create remixes of my latest single, Trust, using my Gentoo setup.

It's kind of a current mini-dream of mine to release an entire album and be able to say I did it in all in Linux.

Why would there be no benefit to running Ardour from a ramdisk (ramdisk noob)?

A tmpfs mount will swap long unused things out to swap drive if memory runs low. A ramfs mount will not. The equivalent mount is

Code:

mount -t ramfs -o noauto,user,size=660m ramfs /mnt/ramdisk

There's no need to use the old kernel ramdisk mechanism: no modules to build, load, or configure.

The problem with ramfs is that there are no limits, the size option will actually be ignored, as as it can't be swapped out you can very easily consume all memory (and even OOM killer won't be able to help you).

That's why tmpfs is a better solution, and if you don't want swapping either `swapoff`, or set "/proc/sys/vm/swappiness" to something quite low.
Alternatively, you can use a real ramdisk, which will never be swapped and won't grow beyond the size you create it as, however you need to create a real filesystem upon it, and you can't reclaim memory by deleting files from it, only by destroying the ramdisk when finished with it._________________"You have to invite me in"

Hopeless, I think I'm on the right track adjusting my jack settings and allowing the latency to ratchet up slightly. It looks like I can skip the ramdisk idea, but I'm going to keep all this info handy for other purposes.

save as 'save ramdisk to HD.sh' in /home folder; change permissions to executable. Then create symlink to desktop.

Now you have a ramdisk created and mounted at boot and scripts to load and save ramdisk contents making it a quasi-persistent ramdisk. You could also add script texts to rc.shutdown and rc.sysinit to occur at startup and shutdown irrespectively! However the option to perform these tasks manually at will is reassuring. Two more scripts could be written to delete contents 1) of ramdisk 2) of ramdisk save