4 ms·

I'm a bit amazed he doesn't even mention [double buffering](https://en.wikipedia.org/wiki/Multiple_buffering https://en.wikipedia.org/wiki/Multiple_buffering),

by bartl 10y ago

I'm a bit amazed he doesn't even mention [double buffering](https://en.wikipedia.org/wiki/Multiple_buffering https://en.wikipedia.org/wiki/Multiple_buffering), a system that was already used in old video games to avoid flicker, as a way to draw on scene screens and only pass it on to the video stage once the scene is complete. All you would need here is 2 (or more) copies of the shared data structure and a few pointers to the data structure. You fill in a draft version of the data structure and only change the "read" pointer to point to it when it's ready. Changing that pointer is, I would hope, atomic. You can then change the "write" pointer to point to a different copy of the data structure to work on. To make sure the client only reads consistent data, it can make a copy of that pointer before it starts processing, because the pointer itself might change. Using 3 buffers instead of 2, and if you're sure the processing of a buffer takes less time than the switching cycle time, you can be sure your buffer data will not ever change in the meantime.

JoachimSchipper 10y ago
Double buffering isn't very suitable for audio. You're right that a suitably-large buffer would allow non-realtime code to "render" e.g. a tenth of a second of audio and pass it off to the realtime audio thread (and/or the audio subsystem, if that has sufficiently-large buffers on your platform). Unfortunately, such large buffers also introduces significant latency; the added latency is fine if you're a music player, but is pretty nasty for interactive applications.
- squeaky-clean 10y ago
  The audio doesn't need to be double buffered. I think GP means you can avoid the author's examples with locks by double buffering the array of keyboard keys being pressed. You don't need to lock either the UI or audio thread, and can ensure they're both seeing uncorrupted data.
SonOfLilit 10y ago
But he does, under another name...
leddt 10y ago
Is this a common technique in audio? In graphics programming, if you are not done with a frame when it would be the time to show it, you can just delay it and it won't cause much problems. In audio, if you are not done processing the data when it should be playing, you WILL hear a glitch. Is double buffering really that useful then? Can't you just maintain a write pointer into a circular buffer that is always ahead of the read pointer?
bodhi 10y ago
If I understand you correctly, you've just increased your output latency by 50% ;)
kabdib 10y ago
I worked on an audio system where the response to buffers bottoming-out was to add more buffers. We had buffers everywhere; in the apps, in the audio pipeline, in the USB stack. Ran into a glitch? Go from 5 buffers to 7. Numerology was everywhere. So what happened was that latency was utterly unpredictable, and we had buffers that went dry (starving the output DAC) or filled up anyway. I'd walked into the project a couple years earlier, and wound up spending six cumulative months getting a handle on all the problems, which were distributed amongst several different code bases, and ultimately involved fixing bugs in every single component, including a really nasty one in the OS hypervisor. It was quite a ride. Isochronous audio is hell. Sure, y'all are smarter than the average bear, but . . . isochronous audio is hell, and you're gonna need rollerskates. :-)
- korethr 10y ago
  >and you're gonna need rollerskates. :-) What does that even mean?
zbuf 10y ago
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.
0x0 10y ago
This is more about safely accessing the shared source data structures (parameters, notes, user input etc) rather than safely accessing the output buffer.

by bartl 10y ago

JoachimSchipper 10y ago

Double buffering isn't very suitable for audio. You're right that a suitably-large buffer would allow non-realtime code to "render" e.g. a tenth of a second of audio and pass it off to the realtime audio thread (and/or the audio subsystem, if that has sufficiently-large buffers on your platform). Unfortunately, such large buffers also introduces significant latency; the added latency is fine if you're a music player, but is pretty nasty for interactive applications.

squeaky-clean 10y ago
The audio doesn't need to be double buffered. I think GP means you can avoid the author's examples with locks by double buffering the array of keyboard keys being pressed. You don't need to lock either the UI or audio thread, and can ensure they're both seeing uncorrupted data.

SonOfLilit 10y ago

But he does, under another name...

leddt 10y ago

Is this a common technique in audio? In graphics programming, if you are not done with a frame when it would be the time to show it, you can just delay it and it won't cause much problems. In audio, if you are not done processing the data when it should be playing, you WILL hear a glitch. Is double buffering really that useful then? Can't you just maintain a write pointer into a circular buffer that is always ahead of the read pointer?

bodhi 10y ago

If I understand you correctly, you've just increased your output latency by 50% ;)

kabdib 10y ago

I worked on an audio system where the response to buffers bottoming-out was to add more buffers. We had buffers everywhere; in the apps, in the audio pipeline, in the USB stack. Ran into a glitch? Go from 5 buffers to 7. Numerology was everywhere. So what happened was that latency was utterly unpredictable, and we had buffers that went dry (starving the output DAC) or filled up anyway. I'd walked into the project a couple years earlier, and wound up spending six cumulative months getting a handle on all the problems, which were distributed amongst several different code bases, and ultimately involved fixing bugs in every single component, including a really nasty one in the OS hypervisor. It was quite a ride. Isochronous audio is hell. Sure, y'all are smarter than the average bear, but . . . isochronous audio is hell, and you're gonna need rollerskates. :-)

korethr 10y ago
>and you're gonna need rollerskates. :-) What does that even mean?

zbuf 10y ago

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.

0x0 10y ago

This is more about safely accessing the shared source data structures (parameters, notes, user input etc) rather than safely accessing the output buffer.