This post is about squeezing more performance from your microcontroller. If you followed the FIR filter and reverb posts, you will have noticed that we needed to enable compiler optimizations to keep the audio processing time low enough to ensure that all incoming buffers will get processed in a timely fashion – i.e. causing no glitches or other artifacts in the output audio.
While the compiler is particularly smart when it comes to optimization, there are some things that it can miss that you as the programmer can add. Before we get into optimization techniques however, we need to talk about measuring performance.
Over the last year, I have been busy with a project which unfortunately de-prioritized the frequency of blog posts on this website. While the project, called BitMasher, is currently ongoing, I felt that now is a good time to share some of the details and progress made on it so far.
BitMasher is a hand-held audio effects ‘game’ – a mashup of an audio effects box and retro-game elements:
Reverb (reverberation) is a super interesting topic. While the basic physical principle is easy to understand, implementing reverb in digital form is the subject of much ongoing research and development.
In this post, we will be making use of the comb filters that we learned about in previous posts and apply them to create an early type of reverberator, the Schroeder Reverberator.
In the previous posts, we went through the basic exercise of reading audio samples through the ADC and outputting them to the DAC without manipulating the samples. This time, we’re going to kick things up a notch and add a filter to our audio processing chain.
In the previous post, we created a very basic example that read a sample of audio from some input and routed it directly to output. At a sample rate of 40 kHz, this sequence of events repeated every 25 usec.
This is fine, provided that any processing you do on the sample does not last longer than 25 usec. Apply any heavier processing however and you run the risk of having your audio sound something like this:
The first couple of posts went through setting up the hardware and the development environment. In this post, we’re going to make use of what we’ve learned so far and create a simple audio pass-through unit.
The last post went into the hardware details for our audio project. In this post, we’re going to cover the coding environment. Aside from the basics, there are some neat features in the microcontroller that we definitely want to use and that’s going to need some extra configuration.
The extra configuration steps sent me on a bit of a wild goose chase throughout the internet so I hope that by compiling most of what I learned into one post, you can get started more quickly.