Fixed buffer sizes are used. Rx use s 3456 x 1st downsample rate x 5
audio frames of buffer space. On Windows this means that each
chunk (periodSize()) delivered from the audio stream is our initial
DSP processing chunk size, thus matching audio buffer latency exactly
with WSJT-X's own front end latency. This should result in optimal
resilience to high system loads that might starve the soundcard ADC of
buffers to fill and case dropped audio frames.
For Tx a buffer sufficient for 1 s of audio is used at present, on
Windows the period size will be set to 1/40 of that which gives
reasonably low latency and plenty of resilience to high system loads
that might starve the soundcard DAC of audio frames to render. Note
that a 1 s buffer will make the "Pwr" slider slow to respond, we may
have to reduce the Tx audio buffer size if this is seen as a problem.
This is a first cut at this to evaluate buffer size adjustments on
supported platforms. A final version might limit status bar reports to
>1000 dropped frames or similar.
Adjusting these may help with audio drop-outs, particularly on slower
CPU systems or heavily loaded systems. Smaller buffer sizes leave less
margin for process interruptions, larger sizes waste resources that
could impact other processes.
Includes a re-factoring of the WSPRNet class, particularly to handle
direct spot posts as well as via a file from wsprd. Switched from GET
http request method to POST method.
FST4W spots post the same information a WSPR spots except the drift
field is always zero (FST4W has no drift compensation, so no drift
figure is calculated by the decoder), and the mode field reflects the
T/R period in minutes. This means FST4W-120A will be similar to
WSPR-2, an FST4W-900 will be similar to WSPR-15. I don't see any way
to view the mode field on either the new or old database format
queries on WSPRnet, so it is hard to tell if that field is actually
stored.
