[hpsdr] Subject: Re: FFT latency

Wed Apr 8 08:15:33 PDT 2015

Hi Michael,

Computation time has nothing to do with processing delay. In this discussion we assume that it is small enough so that all 
computations are finished before the next block (or sample) arrives.

Data blocking is one source of delay. Most soundcards and many SDR radios deliver data in blocks, which introduces a delay equal 
to the block length. This delay may be reduced or eliminated by better hardware and protocol design.  Hermes that you mention in 
your question sends data in packets for technical reasons, there is no fundamental requirement to do so. Its firmware could be 
re-written to deliver one sample per packet - this would require faster hardware than we currently have, but the output signal, 
processed one sample at a time, would still be exactly the same as in the case of block processing.

There is another type of delay that cannot be reduced without sacrificing the quality of the output signal, no matter how fast 
our radios, networks and computers are. In a properly designed system it dominates the overall signal delay. This delay is 
caused by the fact that to compute the output sample corresponding to the current input sample, we need to know the samples both 
before and after the current one. We have to wait until enough samples after the current one are received before we can compute 
the output. One example of such processing is a FIR filter. There is a fundamental relation between the filter length and its 
transition bandwidth (the width of the transition region between the passband and stop band):

Bandwidth = 4 * SamplingRate / FilterLength.

The factor of 4 is approximate and depends on the particular impulse response, but it cannot be much smaller than 4. using this 
equation, you can find out that the transition bandwidth of a 256 tap filter at a sampling rate of 384 kHz, mentioned in your 
email, would be 6 kHz. Imagine a 500-Hz CW filter with its skirts spreading +/- 6 kHz around the passband. Such filter would not 
be very useful, a good CW filter should have a transition bandwidth on the order of 25 Hz to achieve a shape factor of 1.1. Such 
filter would have a kernel length of 65535 samples and a delay of 85 ms - way too long for QSK.

Note that filter delay does not depend on the sampling rate. If you change the rate and filter length by the same factor, the 
transition bandwidth and delay (in seconds) stay the same.

Another misconception is that an IIR filter would have much smaller delays than a FIR filter. This is not true, IIR and FIR 
filters that have comparable bandwidth and shape factors also have comparable delays - this is a fundamental relation that holds 
for all filter types. To achieve good transition bandwidth, you need information contained in the samples after the current one, 
no matter how you process those samples.

73 Alex VE3NEA

On 2015-04-08 09:41, Michael wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Alex,
> thanks for the explanation as people are mixing up different areas of delay. But is the FFT / iFFT and processing in the
> frequency domain really the driver for relevant delay, with today's PCs?
>
> According to http://www.fftw.org/speed/ a modern PC can do a 1024 FFT / iFFT in about 10 - 20 microseconds. Applying some
> filtering in the frequency domain, like spectral subtraction or multiplication with a transformed filter kernel will add some
> more microseconds.
> But all very much below Peter's requirement of '20 ms is acceptable'. Even if the buffer size of 1024 has to be doubled to 2048
> to allow overlap/add processing the overall delay for transform & process is in us rather than ms.
> So where is the delay coming from? I think it is implied in the design of block based processing and other factors, depending on
> processing in the time or in the frequency domain.
>
> a) Processing in time domain sample by sample
> IF the samples would be available one by one (e.g directly from an ADC) the only delay here is to fill up the filter kernel
> until every new sample is included in the output calculation/convolution. If sampled at 384k the delay with a 256 tap filter
> kernel will be below 1 ms (relevant, but no show stopper). But Hermes does not work this way. The samples are delivered block
> based by USB/Ethernet even if all processing is strictly in the time domain.
>
> b) Processing in frequency domain block based
> As shown above the transformation and processing should take a few 10 us, but samples have to be available block based (which
> drives ms delay) to do an FFT / iFFT.  Even if these blocks get small the delay is much more than overall transform and
> processing. Unless the sample rate gets very high...
>
> If I understood correctly Hermes pushes out 512 sample blocks via USB/Ethernet at a sample rate of 384k/192k/96k etc. (one
> panadapter). So there is no way to eliminate this kind of delay until the overall HW design is changed. For a very low latency
> receiver either the sample rate (of the transferred data) has to go up much more or/and the block sizes have to be much
> smaller.  This would call for a kind of streaming mode...
>
>  From my experience with SDR based on C++ and LabView most delay arrives on the PC by audio APIs and a lot of 'side' processing
> to display spectra etc (which requires larger audio buffers to allow this).
>
> PS: I have no clue about FPGA programming yet and did not take a close look into PowerSDR, so I apologize if something is
> wrong... but definitely a more flexible FPGA configuration in Hermes to allow changing the Ethernet packet buffer sizes and
> larger windows (= higher sample rate) would be very nice.
>
> 73 Michael DG5MK
> _______________________________________________
> 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/
>
>

 1428506133.0