IFFT performance on Lich with OWL3 vs Genius

damikyu · June 21, 2023, 1:19am

I recently received an OWL3 upgrade board for my Lich so I thought I’d give a go running my Spectral Harp patch on there but discovered it was having buffer underrun issues and could run with the full 4096 spectrum that Genius uses. This seems strange because as far as I am aware the chip on the OWL3 board is the same as the one in Genius? I created a very simple test patch to eliminate all possible causes of the discrepancy:

github.com

ddf/OwlPatches/blob/main/OwlPatches/FFTTestPatch.hpp

#pragma once

#include "Patch.h"
#include "FastFourierTransform.h"
#include "FloatArray.h"
#include "ComplexFloatArray.h"

#define SPECTRUM_SIZE 2048

class FFTTestPatch : public Patch
{
  FastFourierTransform* fft;
  ComplexFloatArray complex;
  FloatArray output;

public:
  FFTTestPatch() : Patch()
  {
    fft = FastFourierTransform::create(SPECTRUM_SIZE);
    complex = ComplexFloatArray::create(SPECTRUM_SIZE);

This file has been truncated. show original

What I’m seeing is that Lich runs at ~50% CPU when performing a 2048 IFFT and Genius runs at ~12%. What could be going on here?

damikyu · June 21, 2023, 1:57am

After seeing the thread about needing to update Lich with the Lich3 version of the firmware, I thought that might be the issue, but I’m seeing the same performance after a firmware update.

It may still be a firmware issue: my Genius is running 22.4.0 but I can’t update it to 22.5.0 to compare because USB doesn’t work on Genius 22.5.0, so it’s not possible to load the patch.

antisvin · August 11, 2023, 8:38pm

I somehow forgot about this, but had a look now and it’s fairly obvious what’s going on here. OWL used to have a fixed audio block size of 64 samples in the past. Now it’s changed to 32, but Genius overrides it to use 128.

This is typically not too noticeable on normal audio patches where performance scales almost linearly with buffer size, you would just get a few percents of overhead in smaller block sizes. But in this case you run a fixed amount of computation in your patch, while performing it 4 times more frequently.

After rebuilding firmware with #define AUDIO_BLOCK_SIZE 128 in Core/Inc/hardware.h I ended up with ~14% CPU load. Not sure where 2 more percents go, but there could be some difference due to extra computations for handling 7 segment display or different libraries version or something else.

damikyu · August 12, 2023, 3:01pm

Ah ok, that totally makes sense. I thought I saw somewhere that it’s possible to set the block size via MIDI, is that still supported?

antisvin · August 12, 2023, 3:09pm

I think it’s possible in recent FW versions, but never tried it myself. You could use the web config tool for that, enter a setting with BS as key and desired block size as value. I think 512 would be the largest value allowed.

It looks like firmware will restart current patch and audio DMA, so it should be applied immediately without restarting device. And you’d have to save application settings in order for that option to survive restart.