I did some initial benchmarks of the latency of the Circle Teensy Audio Library with the Octo 6-in 8 out sound card. At first I was disappointed. With the standard settings of 44.1khz sampling and a 128 sample buffer, the latency was about 9 ms (milliseconds). Though way better than the 38ms I was getting from the iPad setup, I was hoping it would be quicker. I then tried a few things.
- default setup (44.1khz, 128 sample buffer) - 9 ms
- "short circuit" input buffer to output buffer - 6ms
- decrease buffer size to 32 samples - 3 ms
- increase sample rate to 88.2 khs - approx 1.5 ms
The initial measurement represents the output buffer being 3 full buffers behind the input buffer. This sort of makes sense, but I was hoping it would be 6ms.
The first thing I tried was to short circuit my code, using the same buffers for input and output DMA. I had noticed, due to a bug, before, that this worked, though I'm not sure why. By using the same DMA buffers, data is being read into the buffers FROM the sound card simultaneously as it is being transmitted TO the sound card. It just happens to work, I think, because of the order in which I start the DMA's. It is not a valid measurement, because the system is unusable, basically, with no access to the data in this configuration, but it gives me a rough idea of the minimum latency possible at a given sample rate and buffer size. Since each buffer takes about 3ms to transfer, 6ms means that the transmit buffer is 2 full buffers behind the input buffer.
So, I then decreased the buffer size to 32 samples. with a resultant measured latency of 3 ms. I'm not sure if the reverbs will work, but straight through sound worked ok. By the way, the Octo sounds pretty darned good. I cannot hear any artifacts or distortion at any reasonable listening levels. When I decreased the buffer to 32 samples, it continued to work, but, even without short circuiting. The buffers ARE going through the Teensy Audio Library transmit() and update() processes, so this is a usable configuration.
I then tried upping the sample rate to 88.2 khz - which means BCLK is running at 22.4Mhz and LRCLK at abut 704kHz, and it still worked! I was surprised. I'll have to see how it works with real code (i.e. the reverbs), but this brought the latency down to a respectable 1.5 ms.
In my experience anything under about 2ms and we humans think of it as real-time. Although most folks seem to accept "under 10ms" as functional, I am afraid, particularly early in development, about assuming that is sufficient. So I want to ensure that, in the future, if I need to, that the system can be built to a lower latency specification.