I'm sorry but that analogy is pretty poor: what is the point of using a bucket if there's a hole in it!? In fact, that hole is not a representation of anything that is actually going on in your computer: buffers don't have "holes" or anything equivalent. Also the conclusion you seem to draw from your analogy is that the more tracks you're recording at once, the larger an I/O buffer you need, which is a limited vision of how it works.
Personally I don't really think you need an analogy to understand:
A digital recording is a stream of samples. Each sample is 16 bit or 24 bit (a bit is a value, which can be either 0 or 1) depending on your bit depth setting in your audio preferences. Samples come in at the sample rate determined by your project setting. Let's assume you're recording with a bit depth of 16 bits, at a sample rate of 44,100Hz.
That's a stream of 44,100 samples a second. If you asked your computer to take each sample one by one and put it one after the other in an audio file, that would be way too much work for the computer. See, computers are good at treating large amounts of a data at once, once in a while. They're not really good at treating small amounts of data very often. So 1 sample at a time every 1/44,100th of a second is way too much work. 2 samples at a time every 1/22,050th of a second would already be better. But even better would be, say, a packet of 256 samples every 1/172th of a second. Larger amount of data, less often. Easier on the computer.
We just saw that the bigger the packet (the buffer size), the easier on your computer. That means the CPU is working less, and can do other things, like process that track (or other tracks) with plug-ins for example. That also means now you have to wait 1/172th of a second before you can pass those samples on to the audio file, and another 1/172th of a sec before you can read them back from the disk and send them back out of Logic... so there's a delay between what you record and when you monitor it. That delay is called latency, and increases with the buffer size.
At this point you can see that while recording, a lower buffer size is preferable, as it will give you less latency. But that also means less CPU power, so you may have to mute regions, or bypass plug-ins.
If your buffer is too small for your CPU, the monitoring will start breaking down, and you'll hear cracks and pops, or even total silence.
A little guy (representing your A/D converter) is passing a big strong guy (your computer) a bunch of glasses of water one at a time. But the big strong guy has to take that water to the well located up the hill. The big strong guy doesn't mind heavy loads, but he is limited by the time it takes him to go up the hill, to the well. So he's got two big buckets: one he leaves at the bottom of the hill for the little guy to poor his glasses into while he's carrying the other one (full) up the hill to the well. When he comes back, he leaves his empty bucket at the bottom of the hill and carries the one that is now full up the hill, etc...
Now you can see that since the big guy doesn't mind heavy loads, the bigger the bucket, the easier his job is. Less trips, less often (albeit heavier loads).
Of course, on the other side of the hill, there's another big guy taking the water from the well with big buckets (the output buffer), passing it on to another little guy (the D/A converter) so you can drink your water (monitor your signal).
So you were right that if you have several little guys bringing their little glasses (recording several tracks) then you'll need a bigger bucket. But that's not the only reason, and usually the more important reason for a bigger bucket is a big guy (computer) who's not that fast on his feet. That's usually when you'll want a larger buffer.
Hope that helped?
Last edited by David Nahmani
on Sat Jan 03, 2009 10:03 am, edited 1 time in total.