People don't really talk 'double buffering' in audio, just 'buffering' or ring buffers. I suppose since we're already working in larger (and sometimes flexible)

People don't really talk 'double buffering' in audio, just 'buffering' or ring buffers. I suppose since we're already working in larger (and sometimes flexible) batches of more than two samples. And it's already assumed but he article; it mentions it in terms of "the system has to deliver n seconds of audio data every n seconds to the audio hardware. If it doesn’t, the buffer runs dry". The article is focused on generating the content that has to go in these buffers. Because the problem with just increasing buffering is that it adds more latency. In your triple-buffered video game example, the action is now an extra frame behind the double-buffered case. Hence the focus of audio folks reducing buffers to the minimum; for any audio application that's acting on data from the real world. For example a simple live audio processor, or musical instrument. Small delays of milliseconds seem insignificant but they create various artefacts and effects when that software is used alongside others or in a 'live' scenario. But you are rightly getting at something that is a problem -- that the knowledge of using large buffers for audio seems to have got forgotten in some software; there seems to be a modern assumption that in order to get stable audio without glitches, that realtime threading is necessary and tiny buffers for trivial playback tools. Forgetting that systems did this a long time ago with nice large ring buffers, and the ability to flush or re-fill the buffer.