(The jump between 64 and 128 MB might be a bit coarse.)My standpoint is that if you get into situation when you consider more than 64MB, it's likely that bottleneck is abnormalOr the user is an aberrated personality like me who streams compressed archives on the fly. :))
Keep in mind that ring buffer harmonizes *variations* in input rate. It can't possibly help if the stream can't be maintained at required rate in *average*, no matter how large the buffer is. In other words I find it hard to believe that on-the-fly compression of real-life data affects required ring buffer size very much. If the system is not capable to maintain flow at target average velocity, then you should strive for lowering the recording speed, not increasing the buffer size. But as you still have to pull a lot of data from disk, you still put quite a pressure on VM subsystem, so direct I/O can still help, as it liberates the kernel from scanning the memory to free pages to accomodate "never ending" input in the block buffer [and you effectively get more CPU time for compression]. "Never ending" refers to the ratio between RAM (minus ring buffer size:-) and amount of data to be processed.
Pun aside: with 4x DVD you are of course right. But with 16x DVD a 64 MB buffer gives you just three seconds of reserve.
Yes, which is why I wrote it's on the edge. But idea is also that average Joe will get hypnotized by progress indicator and abstain from pressing the buttons and cause massive page faults while the recording is in progress anyway, while technically minded users like ourselves will figure out what's appropiate in any particular situation [anyway too]. Cheers. A.