Sorry but audio buffers wont do that, mostly for latency reasons.
Please read
this thread, where I explain the difference between disk buffering and audio ring buffering. You're conflating two largely unrelated concepts.
To the degree that larger disk buffers cause latency, it's in the form of a delay when you hit play or record, and even then, only to the degree that the app has to fill the buffer with data. When we're talking about OS-level disk caches (which is what I was talking about), there is no impact on latency whatsoever.
Disk accesses by the OS and apps will lead to clicks, pops and data dropouts.
Why do you have other apps doing significant amounts of disk access while you're recording? Virus? Your disk activity should be at or near zero when your machine is idle unless there's something wrong....
Alway go with multiple drives for audio and video applications; continuous data streaming is a primary goal.
Data from disk can't really be continuous. A DAW typically reads several seconds of audio from each track file on disk in a single request, and on the way back to disk, it writes several seconds in a single request. Making disk requests in large chunks maximizes drive throughput. The DAW makes the read request way, way ahead of when it actually needs the data (measured in seconds), then keeps it in memory until it is ready to play it, then plays it, then tosses it out (usually). As long as that data gets into memory before it is needed, you don't get clicks and pops. Similarly, as long as it gets written out to disk before you run out of RAM to store it, you don't get clicks and pops. Either way, the buffer used for buffering disk reads and writes is completely separate from (and orders of magnitude larger than) the buffer used for moving audio into and out of your audio interface.
More to the point, clicks and pops are, for all practical purposes, never caused by disk performance. They are almost invariably caused by your CPU being unable to keep up with the audio ring buffer used for actually moving audio data into and out of the interface. This, in turn, is usually caused by one of the following:
- Using too small a ring buffer
- Poorly designed USB-1.0-audio-class interfaces (some of which are "USB 2.0" devices) that don't comply with the USB audio spec's requirements for variation in the number of frames per packet (the spec allows for +/-1, IIRC), thus making the audio drivers think that the interface has changed sample rates
- Other drivers holding interrupts off for too long
- Other drivers hogging a PCI bus for too long
- Other apps/drivers/* hogging the CPU.
These days, 5400 RPM laptop drives are on the order of 30-50 Megabytes per second sequential read and write. Ignoring the discussion about how random the accesses are for a moment (they're not very random, unless the DAW is making too short a read/write request), that's 109-182 simultaneous tracks of audio at 96 kHz/24-bit. On some of the slowest laptop drives still being made. Repeat after me: disk performance is not an issue for audio production, and generally hasn't been since last century.
