The two environment variables:
WSJT_RX_AUDIO_BUFFER_FRAMES
WSJT_TX_AUDIO_BUFFER_FRAMES
each can be defined to an integer number which will be used as the
suggested audio buffer size for Rx and Tx respectively. Not setting
the variable or setting it to zero or less will cause the default
buffer size to be used, which should be a good choice for most, if not
all, systems.
WSJT_TX_AUDIO_BUFFER_FRAMES takes the following values:
-1 - use Qt/system default
0 - use 200 mS (WSJT-X default)
+ve integer - value is number of frames at 48 kHz
-1 is likely to be a good choice on Windows and may macOS. 0 has
proven to be good on Windows. On Linux 0 may be OK but we need to try
other values.
The value is only a hint, the actual value used along with the period
size (the size of each chunk of samples requested by the system) is
printed in an info level diagnostic message at the start of each
transmission.
Two new environment variables to control special testing behaviour:
* WSJT_TX_BOTH - set to "1" to force transmission on both periods.
* WSJT_REVERSE_DOPPLER - set to "1" to transpose Tx and Rx Doppler
corrections. Use this to test Doppler tracking on a terrestrial
link.
SWL mode hides all lower panel widgets, maximizing the size of the
decodes windows. Designed for operators running several instances to
monitor multiple bands and modes.
SWL mode hides all lower panel widgets, maximizing the size of the
decodes windows. Designed for operators running several instances to
monitor multiple bands and modes.
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.
