Loading very large files (larger than available RAM) causes system to bog down

Question

My System:
Quad Core (Q6600) @ 2.4Ghz
8GB RAM
OS Drive (7200 RPM)
Audio Source Drive (10k RPM)
Temp Drive (7200 RPM)
(all drives are SATA and internal)
Vista 64 SP1
My most common scenario for using Audition 3 is to load multitrack recordings of concerts and musicals for mixdown. This generally means 12-24 tracks of 24bit/48kHz audio (about 500MB/hour and recordings are usually 1.5 hours - so a 16 track, 1.5 hour recording would mean about 12GB of data to load into the session).
What I see is that everything loads very quickly at firstm, but my available physical memory is also being consumed very quickly. Once my phsical memory is consumed, everything grinds to a halt as the system has to now swap out to disk to free memory before loading the next chunk of audio. During this time, the entire system is pretty much unusable. Once everything is loaded (sometimes after a _long_ wait) Audition functions normally, but as the physical memory on the system is still all consumed overall performance of the system, and Audition, noticably suffers due to the constant ongoing swapping between RAM and disk whenever a new operation is needed. Only on exiting Audition does the physical memory get released.
What is interesting is that Audition is a 32bit program and should not be able to consume this amount of memory, and this is borne out by the Working Set being as small as 20MB at some points, and the commit size under 300MB. I've been told that what I am seeing may be Vista caching those files for the application (I saw this on XP as well for the record), and that the only way to stop it is for the application to load the files with an instruction that they not be cached. From MSDN, I find the OpenFileById function that takes a DWORD dwFlags as a parameter, and in there one of the flags is FILE_FLAG_NO_BUFFERING 0x20000000 which looks like it does what I'm thinking of but brings along a number of restrictions.
Anyways, what I'm looking for is:
1) Are there any settings I can use to mitgate this issue? I haven't found anything yet.
2) Are there changes to my system that would help? I could move to a system with 32GB RAM and never see this again (until I go for even bigger projects!) but that's a bit impractical - though it appeals to the geek in me. I have moved my swap file to the temp drive already and disabled SuperFetch.
3) Any chance this could be addressed in future versions of the product or am I so far out on a limb here that there's no hope for me?
4) I've tried breaking the recordings into chunks to work on separately, but this has always been a clunky experience that's generally more trouble than it's worth. Are there other workflow methods I should try - what do you do with large recordings like this?
Thanks!
Aleks

Answer 1

Aleks, you are using this harder than anyone I can think of. These are great questions and I hope somebody who understand what's happening "under the hood" can answer them.
I have run a rare 90-100 minute session with track counts along those lines, and more, but not necessarily with wave blocks that are continuous for the length of the entire session. The system resources were definitely challenged, but I did not see the behavior that you're experiencing. And that's with far less RAM.
My unofficial take is that Vista 64 is behaving very differently than XP32, which is what I use. In other words, I am presuming that if you were on XP Home or Pro, this RAM-swapfile issue wouldn't be happening. Audition is compatible with Vista only to the extent that Microsoft was forthcoming with information that the developers needed, and if you've been reading here for long, you might have seen that things could have been better in that area. More importantly, Audition is "certified" for 32-bit OS use only, though you're not the first to try it or want it in a 64-bit environment.