Page 2 of 2

Re: Problem importing large files

Posted: Thu Dec 16, 2010 12:59 am
by Gale Andrews
I have not used them, but here are a couple of free Windows RAM drive utilities:

Dataram : Windows XP or later (free for drive creation up to 4 GB, minimum 512 MB RAM required)


Gavotte Ramdisk : Windows 2000 or later (free, no limit on drive size creation, minimum 256 MB, supports FAT16,FAT32, NTFS)

Some users report that Audacity's RAM caching is less likely to crash if other applications than Audacity are being used - perhaps this is because the OS then manages its memory more proactively.

Since (except when recording) Audacity writes its data to disk as well as to RAM, I can see little benefit in using its RAM caching feature unless you have a very slow drive. Of course, writing edits to disk as well as RAM does allow the project to be recovered if it does crash.


Gale

Re: Problem importing large files

Posted: Thu Dec 16, 2010 4:28 am
by scaud
Thanks for the helpful info. I didn't know that disk writing mirrored RAM caching outside of recording. That does foil my expectation of faster operations. In fact Audio caching should produce slower operations as both memory and disk must be updated instead of just disk. Sounds like the RAM drive, however clunky, is the way for best performance.

Re: Problem importing large files

Posted: Thu Dec 16, 2010 5:51 am
by Gale Andrews
scaud wrote:Thanks for the helpful info. I didn't know that disk writing mirrored RAM caching outside of recording. That does foil my expectation of faster operations. In fact Audio caching should produce slower operations as both memory and disk must be updated instead of just disk. Sounds like the RAM drive, however clunky, is the way for best performance.
As i understand it, if you have caching "on" and your remaining RAM is above the threshold set in preferences, Audacity will use the RAM cached data as soon as it's written, and the writing of edited blockfiles to disk will be carried on in the background if not completed. So caching should still be "somewhat" quicker on a really slow drive if you were editing an entire track and so having to rewrite all the blockfiles. As Steve says though, in that case the log jam tends to be the screen redraw rather than waiting for the drive and I suspect the redraw could be slower if you have RAM used up for data cache.


Gale