[hpsdr] FFT latency

[Scott Traurig]

You are not missing anything. Latency is an inevitable trade-off associated
with digital signal processing.

To use the ANAN series of (Hermes based) radios as an example, transmit
audio latency has been characterized to be approx. 40mS *before* any
additional delays caused by the Phone DSP Buffer size setting. This is
because audio must be digitized, sent over the Ethernet to the PC,
processed by the openHPSDR software, then sent back to the radio over
Ethernet. If the VAC facility in openHPSDR is used to obtain transmit audio
rather than the front panel microphone connector, this latency can range
from 40mS using ASIO sound drivers to 2 to 3 times that for Windows sound
drivers.

The Phone DSP Buffer (a misnomer, this is really the length of the audio
passband FIR filter) will add additional delay that is equal to the buffer
size divided by sample rate. As the internal audio sample rate in that
section is 48KHz, this can add an additional delay of between 5.3mS for a
buffer size of 256 and 341.3mS for a buffer size of 16384. Larger buffer
sizes (larger FIR filters) produce sharper passband filter skirts.

Most ANAN operators use a DSP Phone Buffer size of 1024 or 2048 to achieve
passband filters skirts that are already very sharp at that filter size.
They thereby experiencing a total transmit latency of approx. 62 or 83mS
(including the baseline 40mS) depending on the buffer size selected. One
can expect similar latency on the receive side, for a total receive to
transmit latency of say, conservatively, 160mS. This does approach your
suggested 1/5 second limit, and it is certainly noticeable.

Operators who use digital audio workstation software to process their
transmit audio can see additional transmit side delays in the range of
50mS, pushing the total receive-to-transmit latency right up against the
suggested 200mS "comfort factor". There are many who do this, including
myself. It is something that you get used to and it does not substantially
affect break-in style multi-way QSOs, but it is noticeable. Obviously in
nets and roundtables this is not an issue. It's not even that big an issue
for DX pile-ups. I have noticed, however, that 200mS seems to be *far* too
much for contesting, where everyone is speaking so fast one can barely get
a word in edgewise. In this latter case the solution is to trade-off
sharper passband filter skirts for speed and reduce the DSP Phone Buffers
to 256, and perhaps also bypass external audio processing, if used. In the
ANAN using Puresignal linearization this can be done with relative impunity
on the transmit side, as linearization effectively creates a sharp cut-off
on the transmit passband compared to non-linearized implementations.

73!

Scott/w-u-2-o

On Sun, Apr 5, 2015 at 6:54 AM, G3XJP <G3XJP at rhodesg3xjp.plus.com> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> I need your collective wisdom!  Is it not an inescapable fact that any
> serious FFT in the real-time path between your antenna and your ears must
> introduce an inherent and inevitable delay that will preclude a
> conversational VOX/QSK QSO?  I can see that it would not preclude listening
> to a monologue - or to watching spectral pictures on a display.  But
> anything more than about 1/5 sec is doomed to feel like Skype on a bad day
> - where you often end up having to say "over".  As a generality, am I
> missing something fundamental here?  Peter G3XJP
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20150405/9c36614f/attachment-0003.htm>