i would like to know the latency of the owl modular.
Hi Olaf - thanks for re-posting this on the forum!
So the latency depends on the blocksize and sample rate. The current firmware runs at a rate of 48kHz and default blocksize of 128 samples, which means each block takes 128/48k = 2.67mS (milliseconds). The microcontroller’s DMA unit reads and writes using two different buffers, both of length blocksize*2 (double buffered), meaning that while one half of the buffer is filling up (or emptying out), another is being processed. So our latency is two times the blocksize, by default apprx 5.3mS.
The blocksize can be reconfigured from 4 to 1024 samples (in powers of two, e.g. 4, 8, 16, 32…), giving us a latency range from 160uS (microseconds) up to 42.7mS. Jitter, afaik, is non-existent.
Regardless of blocksize, the processor has an upper limit of 3500 operations per sample. Since there are some overheads to setting up a block, big blocks can be more efficient than short ones. A patch developer can choose to perform expensive calculations at block rate, leading to better performance overall. Generally speaking, 128 is a good compromise between low latency and good efficiency. For certain types of patches, e.g. when performing FFTs, you might want a bigger block size that matches your FFT window.
Computers and smart devices typically have an additional buffer stage, and bigger block sizes, leading to latency up to (frequently over) 20mS, which is considered noticeable by most (depending on the type of sound).
You mentioned it is even possible to run patches programmed in a way that they do not use the DMA (Direct Memory Access). How is this possible?
It’s certainly possible to run the hardware in such a way that you process sample by sample, but our API does not support it since it is block based. You would have to make changes to the firmware directly to do this.
The only possible advantage that I can see is near zero latency. What is your application?
My application would be in a feedback based modular system … so low latency can be very important. I talked again with a friend about latencies of ADDA converters he highlighted that all converters have a latency (he mentioned usually 20ms) did you ever made measurements?
Total latency depends on many factors, for computers / laptops / mobile devices you can expect at least 20mS but for embedded, bare-bones platforms such as the OWL it can be much less.
Just did a quick measurement on my 100MHz scope: at 128 samples per block the latency is 6.24mS with no discernible jitter. Tested with both OWL Pedal and Modular.
This is a bit more than the expected 5.3mS, and I don’t know if the difference is fixed or varies with blocksize. I’d like to do more measurements with different blocksizes, but I have very little time at the moment. Please remind me in a couple of weeks time!
Squarewave input in blue, OWL Modular output in red. Gain patch, blocksize = 128.
Oh, and feedback based modular systems: this is a nice application that I’m very interested in!
If you have anything particular in mind let me know, I can try patching it up and record a few samples.
I’ve now done some more measurements.
OWL Pedal latency varies from 43.6 milliseconds (mS) at 1024 samples per block, down to 992 microseconds (uS) with a blocksize of 2 samples.
Default blocksize is 128 samples, which gives a latency of 6.24mS.
From the measurements it seems there’s a fixed system latency of apprx 900uS, which is perhaps due to the combination of analogue circuitry (input and output buffers) and codec. However with the codec in bypass mode this comes down to less than 10uS, which leads me to believe that most if it is due to the codec and/or microcontroller.
The OWL Modular has apprx 8uS less latency in my tests than the OWL Pedal. In codec bypass (soft bypass) the measured latency is less than 2uS.
It would be interesting to do some more tests with different MCU configurations, e.g. using sample based processing instead of DMA buffers.
For reference, 6mS latency is equivalent to the time delay you get from standing 2 metres further away from the amp.
Hello Martin, Olaf,
I am interested in feedback applications too, more accurately, in actively controlling an instrument through a FB loop.
The vibration frequency range I am interested in is 50-200Hz.
At 100Hz, a 1ms latency is equivalent to 0.1 phase delay = 36degrees which is way too much to achieve my goals.
Did you guys experiment with a Bela system on Beagleboard ? They claim 100microsecond latency
We work closely with the Bela team, it’s a great platform. I’ve not personally tested Bela latency, but I would expect it varies depending on what component your are measuring: ADC, DAC, or codec.
Typically with a feedback loop you can compensate for a fixed latency. For example, with a periodic signal at 100Hz and 1mS latency, if you need the output to be phase aligned with the input you delay it by an additional 9mS (variable with the signal frequency). The output is then always one whole period behind the input. This works up to 1kHz, at which point you would add 2 periods, et c.
Real problems arise when there is jitter, ie variable latency. With the OWL, there is no jitter at all that I have ever seen.
Found a reference for Bela latency:
“This allows audio block sizes as low as 2 samples, resulting in round-trip audio latency of 1ms (or even down to 100us if using the analog inputs and outputs rather than the audio converters) (McPherson, Jack, and Moro 2016).”
In other words, for audio both OWL and Bela have a round-trip latency of around 1ms.
Hi
with their Audio Expander Capelet, I understand that you can get analog I/O-type latencies (closer to 0.1ms) for audio.
Typically with a feedback loop you can compensate for a fixed latency. For example, with a periodic signal at 100Hz and 1mS latency, if you need the output to be phase aligned with the input you delay it by an additional 9mS (variable with the signal frequency). The output is then always one whole period behind the input. This works up to 1kHz, at which point you would add 2 periods, et c.
Real problems arise when there is jitter, ie variable latency. With the OWL, there is no jitter at all that I have ever seen.
I realize that I did not take time to comment this. Fixed latency compensation is the obvious solution for linear instruments. For non-linear instruments where frequencies are not multiples of a fundamental, your reasoning cannot be applied.
The trouble is, I am trying to work on a 1,40m diameter Wuhan Tam (gong). Highly non-linear, as you can imagine.
Best !