[hpsdr] FFT latency

Tue Apr 7 19:32:19 PDT 2015

The rule of thumb when designing FIR filters that run on a PC was to use
FFT/IFFT for filters larger than 60 to 100 coefficients.

With modern PCs I'm not sure how relevant that now is.

For example, in our Direct Fourier Conversion (DFC) project we are
processing a 1M length FFT in 4mS using cudaFFT on a Jetson board.

This FFTs the entire 0-30MHz spectrum using a 16 bit ADC sampling at 74Msps.

73 Phil...VK6PH

> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi Peter,
>
> In order to minimize the latency of your DSP pipeline, you have to find
> out where the delays actually come from. Contrary to the
> popular belief, FFT does not introduce any delays. Consider this scenario.
> You have a buffer filled with zeros. You receive your
> first audio sample, place it in the rightmost position in the buffer,
> compute FFT, and then compute IFFT. You take the output
> from the rightmost position in the buffer - which still contains your
> original sample. As the next sample arrives, you push it
> in the buffer at the right side, and repeat the process. This pipeline
> includes both FFT and IFFT, but it has a zero delay.
>
> Of course, such pipeline is very CPU intensive and not very useful. In
> most cases we simply do not have enough CPU power to
> recompute the FFT for every input sample. We process samples in blocks,
> and this is the first source of delay. Consider a second
> buffer, say, 64 samples long, that we place in our DSP pipeline before the
> FFT. As we receive samples, we simply put them in the
> buffer. Only when the buffer is full, we push our data in the FFT buffer,
> at the right side, and do our FFT/IFFT work. Now the
> very first input sample has a chance to affect the output only 64 samples
> after its arrives. Note that this delay is avoidable,
> as there is a trade off between the number of FFT's that you have to
> compute and the amount of delay. By changing the size of
> your input buffer, you change the delay, but this does not affect the
> output samples in any way.
>
> Version 2 of our DSP pipeline has acceptable CPU requirements, at a cost
> of some delay, but it still does not do anything
> useful. In order to make it do some work for us, we have to modify the
> data somehow between the FFT and IFFT, and this is where
> a long, unavoidable delay comes into play. Multiplication in the frequency
> domain corresponds to a convolution in the time
> domain, and convolution always shifts the samples back. As has already
> been mentioned in this thread, a convolution with a
> symmetric kernel (impulse response) delays the signal by (N-1)/2 samples,
> where N is the kernel length. Subtraction (as in the
> spectral subtraction algorithm) does not add a delay per se, but the
> values being subtracted, if they change in time, are more
> then likely computed using an algorithm that could be viewed as a
> convolution, which is what causes the delay in your pipeline.
> This delay is unevoidable because if you change the length of your
> equivalent impulse response, you change not only the delay
> but also the shape of the output waveform. To optimize your algorithm, you
> have to figure out 1) where filtering (convolution)
> occurs in your algorithm, 2) what its kernel length is, and 3) how to
> change your algorithm to minimize the kernel length
> without sacrificing the quality of denoising.
>
> The minimum useful kernel length is, of course, algorithm dependent. I
> don't know how you compute the values that you subtract
> from the spectrum, but if you view these values as a frequency response of
> some filter, then the longer the kernel, the sharper
> transitions can be achieved in this frequency response. You should use the
> kernel only as long as is needed to achieve the
> desired filter shape.
>
> 73 Alex VE3NEA
>
>
>
> On 2015-04-07 05:02, G3XJP wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>>
>>
>> Simon, it is precisely LMS noise reduction and auto-notch that I am
>> replacing.  COS - in brief - I don't like listening to
>> voices coming out of a drain-pipe.  The freq domain solution is way more
>> effective. But at a price, namely inherent delay.  So
>> I'm not looking for other solutions.  I just want to be sure those
>> inherent Fourier delays are .... ummmm .... inherent.  Peter
>> G3XJP
>>
>> Simon Brown wrote:
>>> Peter,
>>>
>>> One alternative to FFT-based noise reduction would be adaptive LMS
>>> noise
>>> reduction with ~ 99 taps (or a variable number of taps). LMS can also
>>> be
>>> used with great effect for an automatic notch filter.
>>>
>>> Simon Brown G4ELI
>>> http://v2.sdr-radio.com
>>>
>>>
>>> -----Original Message-----
>>> From: G3XJP [mailto:G3XJP at RhodesG3XJP.plus.com]
>>> Sent: 07 April 2015 09:46
>>> To: Simon Brown
>>> Cc:Hpsdr at lists.openhpsdr.org
>>> Subject: Re: [hpsdr] FFT latency
>>>
>>> gm Simon,
>>> 1) I don't have and don't want a waterfall/spectrum display and
>>> 2) my SDR does not run on a PC let alone Windows.  It runs on a
>>> dedicated
>>> radio.
>>> I do have to have Fourier and his inverse in the real-time signal path
>>> -
>>> because I need to get into the freq domain, do the Noise Reduction
>>> stuff and
>>> then get back to the time domain.  In that sense, FFT and IFFT are pure
>>> overheads, a means to an end.  And I would have to forget the whole
>>> idea if
>>> they produced inherent delays that would make ANY radio on ANY platform
>>> unuseable.  20ms is acceptable.  Only just.  Peter G3XJP
>>>
>>> Simon Brown wrote:
>>>
>>>> Peter,
>>>>
>>>> You don't have to perform FWD / INV FFT in the demodulation path at
>>>> all.
>>>> Essentially there are two IQ paths in a generic design:
>>>>
>>>> 1) For the waterfall / spectrum display,
>>>> 2) For demodulation.
>>>>
>>>> Demodulation can get down to < 20ms on Windows if you're careful,
>>>> using WASAPI audio API helps a lot :) .
>>>>
>>>> Simon Brown G4ELI
>>>> http://v2.sdr-radio.com
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> HPSDR Discussion List
>> To post msg: hpsdr at openhpsdr.org
>> Subscription help:
>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>> HPSDR web page: http://openhpsdr.org
>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help:
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
>

 1428460339.0