I’m currently trying to get an stft class with shy_fft as it’s backend for FFT. Class can be seen here
Currently with an fft_size of 512, and a buffer_size of 680 (fft size + hop size), everything works pretty well.
The issue comes when I either try to window the signal (line 109 and 133 respectively). Any type of window or size combo I’ve applied to the signal seems to create a feedback/choppiness/static on the output signal.
Does anyone have any tips on correctly processing a window here?
This is just a shot in the dark, but it could be that the windowing code adds enough cpu cycles that you run out. You could try reducing the fft or buffer size and see if that makes the problem go away.
I think the underlying problem is that the Process() function can take enough time to cause buffer underrun on the output. It’s risky to put anything in the callback whose timing isn’t very well understood.
Do you have any suggestions on the best way to handle this? I know we spoke about it previously on discord, but when I moved it out of the callback, it actually stopped functioning. Most likely the way that I implemented it was incorrect though
EDIT AGAIN:
// Function to notify that STFT processing is ready
void NotifySTFTReady()
{
stft_ready_ = true;
}
// Function to check if STFT processing is ready
bool IsSTFTReady()
{
return stft_ready_;
}
// Function to reset the STFT ready flag
void ResetSTFTReady()
{
stft_ready_ = false;
}
Through some weird trickery with flipping bools, I now have the processing done in the while loop, outside of the audio callback. I haven’t tested anything too latent/heavy yet, and have yet to apply/test windows, but I’ll check into that and report back!