How/why does audio buffering cause lag in playback?

[Dr. Brule]

I've been doing some reading about digital audio playback, and some of the finer points of buffering confuse me.

Specifically, I keep reading that having a higher buffer size will introduce lag/latency. I'm a little bit confused why this would be; shouldn't it be the opposite? Shouldn't a higher buffer size only ever improve playback, because there's less chance that you will run out of samples to write to the underlying audio output system (e.g. sound card)? Sure, a bigger buffer will take up more computer memory, but assuming (for the sake of argument) you have unlimited memory, why would it still cause playback lag?

My understanding is that in order to get smooth audio playback, the buffer must be supplied with enough samples to send to your audio output. I can understand how having too few samples in the buffer could cause problems, because your audio output system is reading faster than it can write. But why would having more samples in the buffer introduce lag? Doesn't the audio output system just read chunks from the "head" of the buffer (assuming the buffer is a FIFO queue data structure) at whatever rate it wants? If that's the case, then I can't imagine why it should matter how many samples are in the buffer, because it only cares about getting the first n samples (where n is the size of the chunk it wants).

Or am I wrong, and it reads/empties the entire buffer at once? If so, then I suppose I could understand why it would introduce lag, because it would take longer for the audio output system to read the entire buffer contents and process it or something...

Mods: not sure if this thread belongs here, so feel free to move it.

[lordsmurf]

Larger buffers store more data. As such, data takes longer to move through the buffer. Hence larger buffers creating lag.
The same is true of video.

[Dr. Brule]

But doesn't the audio system just consume n samples from the head of the buffer at whatever rate it wants? If that's the case, that would mean the audio system dictates the rate at which data moves through the buffer, meaning the size of the buffer itself wouldn't matter (because the audio system only ever cares about the first n samples)...

[kpmedia]

I really don't understand your question.

The larger the buffer, the more there is to fill at the start of an operation. Once it's full, then the audio starts to exit.
That's the entire point of a buffer. It's designed to be a delay.

The "lag" is only seen in comparisons, or when real-world adjustments are not instant. For example, recording video games.

[Dr. Brule]

Quote:

Originally Posted by kpmedia

Once it's full, then the audio starts to exit.

Ah, that's the key part I was trying to clarify. My (mis)understanding was that samples exit the buffer at whatever rate the audio system dictates, regardless of whether the buffer is full or only partially full. But if audio samples only exit the buffer when is size limit is reached, then yeah, I can see how a larger buffer would cause more lag.

So, just to make sure I understand... Prior to audio playback, the audio system will wait for the buffer to fill to its limit (causing a slight delay before you hear sound). When it reaches the limit, it will empty the buffer and start playing the audio samples it retrieved. While the audio is playing, the audio system will then wait for the buffer to fill to its limit again, and then empty it. And so and so forth until playback is stopped. Is this correct? There is never a point throughout the playback process where the audio system will just empty a partially full buffer, right?

[kpmedia]

It really depends on the kind of buffer.

DVD burner buffers, for example, are there to facilitate uneven drops in read speeds, in order to output a sustained data rate to the burner. As such, drops in I/O will cause the buffer to be less than full throughout the process (anywhere from 1% to 50% usually), and so it's not always 100% full. However, it does fill up initially. The buffer attempts to stay full, but it takes whatever it can get.

If the buffer empties before the process is completed, a buffer underrun occurs. Burners have had buffer underrun protection for about a decade now, and is where the disc continues to spin, but the laser halts and waits for the buffer to 100% refill. Once the refill has happened, the burn process will resume. (Off-topic trivia: If you test the disc, you'll often notice trouble points at the spot where the underrun occurred, so those are often considered bad burns.)

The same is true of streaming video. If the buffer empties, the video will temporarily pause and wait for a complete refill. (In some cases, with lousy setups, the video stream will abort entirely! I saw this a lot with my MLB.tv subscription in 2011 -- it was quite aggravating! The entire game would restart, and I'd have to fast forward back to the correct inning. This has not yet happened in 2012, thankfully.)

With DVD recorders, the input buffer is always full, as the video is processed with noise removal (NR) and sync correction before being passed to the encoder.

But the one fact that remains constant amongst all of these buffers is that the buffer fills at the start of the operation. Due to this, a real-time lag occurs. Whether it stays full really depends on the purpose of that buffer. Not all buffers operate for the same reasons.

I almost think you're confusing a cache with a buffer. A cache can be there "as needed", and can be stored in RAM or on disk. A buffer is there because the need was predetermined, and it's part of the processing workflow regardless.