pfft~ latency calculation

Roald Baudoux

Hello,

Is there a clear way to calculate the exact latency introduced by a pfft~ according to sampling rate, window size, window step and signal vector size?

Thank you.

volker böhm

Yes, FFTsize - SignalVectorSize

Mattebass

Hi, I've just tried something out in order to fully understand this topic, and seems that the pfft~ documentation is wrong, or there's something I'm missing.

I attach a patch that demonstrate what Volker stated, but It's not clear the reason:

Are the samples of a frame collected and then the overlapped part of every window that define the first frame immediately calculated? Or maybe, more realistically, are collected (buffered?) the samples corresponding to the 4 overlapped successive windows and immediately calculated the result of the first frame?

What is the reason to subtract a signal vector size? This is due to the fact that in the current frame the samples are collected and immediately calculated and afterwords is necessary to wait for the successive frame to have the signal out?

Thanks

pfft_delay.maxpat

Max Patch

vector_delay.maxpat

Max Patch

volker böhm

I attach a patch that demonstrate what Volker stated, but It's not clear the reason:

FFTs work on blocks/frames of data. So, in a realtime context, first you need to collect the necessary number of time domain samples (fill the frame) before the transform can be executed. Generally the number of input samples equals the FFT size (with zero-padding things get more complicated!).
This is always like that (logically) and Max is no exception.

BUT: In MaxMSP audio data is also processed in blocks/vectors (albeit smaller blocks). Each signal object receives a block of samples, works on them and passes the block on to the next object. The size of these blocks is specified by the 'signal vector size'. You can think of this signal vector as being part of the overall latency of your audio system.

So, like all other signal objects [fft~] and [pfft~] objects receive their input data in blocks. To calculate the total delay/latency that the FFT objects introduce (e.g. to align the processed output with unprocessed signals), you have to subtract one signal vector worth of samples from the actual frame size, as this is part of the overall latency of your system.

And the overlap factor has nothing to do with the input/output latency.

Roman Thilenius

or in other words, the vectorsize in a pfft is its fft size.

Francesco Canavese

Hi everybody, thanks to Volker explanation it is clear that in the in pfft~ reference there's a quite big mistake...

signal
The output is the result of the FFT-based signal processing subpatch. As with the fft~ and ifft~ objects, pfft~ introduces a slight delay from input to output (although it is less than half the delay than with an fft~ / ifft~ combination). The I/ O delay is equal to the window size minus the hop size (e.g., for a 1024-sample FFT window with an overlap factor of 4, the hop size is equal to 256, and the overall delay from input to output is 768 samples). The number of outlets is determined by the number of fftout~ and/or out objects in the loaded subpatcher. Patchers loaded into a pfft~ object can be given outlets by fftout~ or out objects within the patch. See fftout~ and out for details.

But, also the Volker explanation seem to be not completely accurate... afaik the right calculation should be:

FFTsize - min(SignalVectorSize, HOP size)

i'll open a ticket about this!