<div dir="ltr">You are not missing anything. Latency is an inevitable trade-off associated with digital signal processing.<div><br></div><div>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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>73!</div><div><br></div><div>Scott/w-u-2-o</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 5, 2015 at 6:54 AM, G3XJP <span dir="ltr"><<a href="mailto:G3XJP@rhodesg3xjp.plus.com" target="_blank">G3XJP@rhodesg3xjp.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">***** High Performance Software Defined Radio Discussion List *****<br>
<br>
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<br>
______________________________<u></u>_________________<br>
HPSDR Discussion List<br>
To post msg: <a href="mailto:hpsdr@openhpsdr.org" target="_blank">hpsdr@openhpsdr.org</a><br>
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" target="_blank">http://lists.openhpsdr.org/<u></u>listinfo.cgi/hpsdr-openhpsdr.<u></u>org</a><br>
HPSDR web page: <a href="http://openhpsdr.org" target="_blank">http://openhpsdr.org</a><br>
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" target="_blank">http://lists.openhpsdr.org/<u></u>pipermail/hpsdr-openhpsdr.org/</a><br>
</blockquote></div><br></div>