Optimisation

Circular (ring) buffer plus neat virtual memory mapping trick

I’ve just updated my [C circular buffer implementation](http://atastypixel.com/a-simple-fast-circular-buffer-implementation-for-audio-processing/), adopting the trick originally proposed by [Philip Howard](http://vrb.slashusr.org/) and [adapted to Darwin](http://www.snoize.com/Code/PlayBufferedSoundFile.tar.gz) by [Kurt Revis](http://www.snoize.com): A virtual copy of the buffer is inserted directly after the end of the buffer, so that you can write past the end of the buffer, but have your writes automatically wrapped around to the start — no need to manually implement buffer wrapping logic.

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on [GitHub: TPCircularBuffer](https://github.com/michaeltyson/TPCircularBuffer).

There’s a basic example of its use over on the [original post](http://atastypixel.com/a-simple-fast-circular-buffer-implementation-for-audio-processing/).

A simple, fast circular buffer implementation for audio processing

[Circular buffers](http://en.wikipedia.org/wiki/Circular_buffer) are pretty much what they sound like – arrays that wrap around. They’re fantastically useful as scratch space for audio processing, and generally passing audio around efficiently.

They’re designed for FIFO (first-in-first-out) use, like storing audio coming in the microphone for later playback or processing.

Consider a naive alternative: You copy the incoming audio into an NSData you allocate, and then pass that NSData off. This means you’re allocating memory each time, and deallocating the memory later once you’re done processing. That allocation incurs a penalty, which can be a show-stopper when part of an audio pipeline – The Core Audio documentation advises against any allocations when within a render callback, for example.

Alternatively, you can allocate space in advance, and write to that, but that has problems too: Either you have a synchronisation nightmare, or you spend lots of time moving bytes around so that the unprocessed audio is always at the beginning of the array.

A better solution is to use a circular buffer, where data goes in at the head, and is read from the tail. When you produce data at the head, the head moves up the array, and wraps around at the end. When you consume at the tail, the tail moves up too, so the tail chases the head around the circle.

Here’s a simple C implementation I recently put together for my app Loopy: [TPCircularBuffer](https://github.com/michaeltyson/TPCircularBuffer)