A quick Metaphor about Buffer

To help maybe some people understand what the buffer is, I've heard a pretty good metaphor I'm going to share.

 

The buffer is like a bucket, with a hole on the bottom. Every audio that goes in or out of your computer goes trough that bucket. The hole is always as big, unrelevant to the size of the bucket itself.

 

So if you have a small bucket (low buffer), and you pour a lot of audio into it (let's say, recording 16 tracks at once) the hole in the bucket won't keep up with the audio coming in, and the bucket will overflow (causing system or disk overload)

But if you are recording for say, only one track, the audio goes straight trough the hole, giving you very little latency for input monitoring.

 

Now if you have a large bucket (high buffer), you will easily record 16 tracks of audio, since the audio "piles up" before getting trough the hole in the bucket, as you try to input monitor all the tracks, you will get a bit of latency.

 

Hope this makes sense, and gives you a bit of Idea of what the buffer is about.

from Wikipedia "In computing, the term bucket can have several meanings. It is used both as a live metaphor, and as a generally accepted technical term in some specialised areas. A bucket is most commonly a type of data buffer or a type of document or in which data is divided into regions."

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.

 

SO:

 

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.

 

Suggested analogy:

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?

Edited January 3, 2009 by David Nahmani

Thanks for offering your analogy, but it is, I'm afraid, a bit incomplete and a little inaccurate.

 

[EDIT: having read David's reply, posted as I was writing mine, I advocate the "hole in the bucket" analogy]

 

"I/O buffer" implies that there is are two buffers: one on the way into Logic, the other on the way out. Actually, every digital audio device has an input buffer and an output buffer of some kind. I'm not 100% clear on why both I and O buffers are set to the same value via a single parameter (perhaps someone else can explain).

 

The I/O buffer is not the only buffer in a DAW either. In Logic, for instance, there's the process buffer (small, medium, large). But let's just keep with the I/O buffer for simplicity sake. The idea of using a bucket as an analogy for how the buffer(s) work is a good one, though it needs to be more accurately described, and a few technical details need to be understood...

 

Your computer can operate at a much faster speed than the sampling rate of audio. Let's consider the 44.1K sampling rate and what happens when a single mono track is played back: every .02 milliseconds, the interface gets a sample to play back. That's one sample every two-ten-thousandths of a second. Compare that rate with the speed of your computer, which is likely up in the Gigahertz range (billions of operations per second). The audio playback rate is much slower! If your computer operates at 1GHz, there are 200,000* instructions that the computer can execute inbetween the task of reading each sample and spitting it out to your interface.

 

So your computer can not only play back a sample when needed, but also do all manner of other things inbetween playback of samples. Still, speed alone doesn't ensure that your computer can keep up with it all, as those 200,000 cycles can be eaten up with all manner of things (redrawing screens, updating the display of the clock on your menu bar, reading more samples from disk and loading them into memory, etc.)

 

And the load on the computer's processor is always variable, as easily seen by looking at the system performance meter at any given time.

 

So to continue with this example (playback of a mono track), we're not asking very much of the computer or Logic. Here, Logic might have, say, enough time to process (read) 17 samples of your audio track and place them in the buffer before the computer is called upon by some other operation (an "interrupt") that has nothing to do with audio playback. By the time it's finished with that other operation, maybe 10 of those samples have been clocked out of the buffer and sent to your interface. That's pretty good! There's still a safety margin of 7 samples left to be read. And during that time, maybe your computer finds that it has time to place 12 more in there before it gets interrupted by some other process. So in an ideal situation, the buffer (bucket) fills up faster than the data is read out. And here, a buffer size of 32 might work just fine. That "32" means "32 samples", BTW.

 

So the buffer is like a "safety net" that ensure that a continuous stream of audio can be played out of Logic uninterrupted while the processor is called upon (interrupted) to do other things.

 

Regarding the "hole in the bucket"... Your audio system is content to read out the samples from the output buffer, one at a time, at the sample rate which we've already established is at a much slower rate than the computer actually fills up the bucket. So as the bucket fills up there's a small hole out of which the audio "drips into the interface". But...

 

The more you tax your computer (high track count, lots of plugins, simultaneous recording of audio while playing back other audio, etc. etc. etc.), that buffer size of 32 might get emptied because the computer hasn't had time to fill it up in time. Larger output buffer sizes literally tell Logic that it needs to prepare more audio for playback ahead of time, and this ultimately gives Logic more "breathing room" to do its processing (as well as leave free cycles for the computer to be interrupted by other system processes).

 

So the hole in the bucket ALWAYS remains the same size. It's the size of the bucket that changes when you adjust the buffer size.

 

* Nitpicker Alert: this is an example for illustration purposes and obviously not 100% technically accurate.

So as the bucket fills up there's a small hole out of which the audio "drips into the interface".

 

That's where that "hole in the bucket" analogy breaks down: a computer never transports or processes samples as a bucket is being filled. Only once a bucket is fulled can it be transported and/or processed. The computer doesn't "drip" samples to the interface from a buffer that is being filled, instead, it waits to fill a whole buffer, and then starts streaming it to the interface.

 

So there are, in your computer, no holes in the buckets.

 

I suppose you could make a case for an analogy where once the bucket is full, you open a hole at the bottom to stream its contents back out of the computer... but only once the bucket is full, not as it is filling up.

Edited January 3, 2009 by David Nahmani

Well, you got me there Altough that was an explanation I heard somewhere, can't really recall where. But the point of having a bucket would be if you are trying to pour 5 liters of water per second one second, and 3 liters per second the next, but the input could only take 4 liters per second, then the extra liters would be stored in the bucket until the drain would be able to take it.

 

But thanks for correcting me

 

It actually sounds easier without the metaphor:P

 

 

inflex: my bucket had nothing to do with the computing term.. It's simply a container for water..

But the point of having a bucket would be if you are trying to pour 5 liters of water per second one second, and 3 liters per second the next, but the input could only take 4 liters per second, then the extra liters would be stored in the bucket until the drain would be able to take it.

 

No, that's not the point: you don't record 3 tracks one second, 5 tracks the next, during the same recording. In fact the data is coming to your computer at an extremely regular rate, there's nothing to "smooth out". The point of the bucket is to pass bigger packets of data at a slower rate, rather than smaller packets at a higher rate.

The hole in the bucket is merely an analogy for the output of the buffer.

 

Per my understanding of how these things work, the buffer can afford to be filled to the maximum but it cannot afford to be emptied completely before the audio system expects a new sample (or in your description, David, a "packet"). The warnings of "audio could not be processed in time", etc., are a representation that the buffer (bucket) was emptied before it could be filled again. This means (in many cases) that the buffer size is too small.

 

Again, per my understanding (which, who knows, might need some clarification itself), the buffer is there to provide "breathing room" for the processing of audio. In other words, audio needs to be processed and made ready for the audio system to play back in advance of the need to hear it. So if the buffer is too small, Logic can't process the audio and place it in the buffer fast enough in time for the next expected sample (packet) to be read.

 

David, does that clarification "hold water" with you?

The hole in the bucket is merely an analogy for the output of the buffer.

 

The reason I don't like that analogy is because you never, ever have anything going through the hole as you're filling the bucket through the top. So why have a hole in the bottom? I'd rather say: fill up the bucket, and once it's full, you can slowly pour it into a file, another bucket, or an output port on your computer.

 

In my descriptions, a packet is not a sample, it's a buffer full of samples.

inflex: my bucket had nothing to do with the computing term.. It's simply a container for water..

 

Of course, I was just refering to Wikipedia's definition (not always accurate) of bucket (container for data)

We should simply stick to the manual:

 

I/O Buffer Size

 

This parameter determines the size of the buffer used by the audio hardware—for both input and output. The smaller the buffer size, the less latency you will encounter when monitoring while recording, or using software instruments.

 

Some points to note:

 

As this parameter value is reduced, it places a higher strain on the CPU(s) of the system.

 

There may be a point where the selected I/O Buffer Size is too small for your system, and begins to affect playback. This usually takes the form of clicks, pops, and crackles in your audio.

 

You should, therefore, aim for the lowest possible I/O Buffer Size value that doesn’t introduce these types of artifacts.

 

Tip: If you find a higher I/O Buffer Size setting provides suitably low latency during record monitoring and software instrument playback, you should use it. This will minimize the impact on the CPU(s) of your system.

 

Now we can kick the bucket and move on... Let's talk about Fluffers instead of buffers.

I don't think their will be any debate about the purpose of the fluffer, and from my understanding the number of available inputs is generally underutilized. Maybe I should shut up now...

 

 

More [ahem] on topic... There are different kinds of buffers in digital systems. A keyboard queue (a buffer that accumulates computer keyboard keystrokes, which get processed in the order received but not necessarily simultaneously as in a packet) is one type. Then there is the audio buffer, the functioning of which I'll defer to David's explanation since he's usually not wrong about these things. However, David, I'm confused about your use of "slowly" in your post above:

 

"...once [the bucket is] full, you can slowly pour it into a file, another bucket, or an output port on your computer."

 

Why "slowly"?

Edited January 4, 2009 by ski

So there are, in your computer, no holes in the buckets.

Phew! That's a relief. Although my old windoze laptop still leaks. It's a bear to clean up. (Clogs the filter in my vacuum.)