Using a local event loop to wait for Omni-Rig to initialize has caused
issues elsewhere, reverted to simple waits in teh hope that Omni-Rig
initializes promptly.
Default selection is the loop-back interface. Users who require
interoperation between WSJT-X instances cooperating applications
running on different hosts should select a suitable network interface
and carefully choose a multicast group address, and TTL, that has
minimal scope covering the necessary network(s). Using 224.0.0.1 is a
reasonable strategy if all hosts are on the same
subnet. Administratively scoped multicast group addresses like those
within 239.255.0.0/16 can cover larger boundaries, but care must be
taken if the local subnet has access to a multicast enabled router.
The IPv4 broadcast address (255.255.255.255) may be used as an
alternative to multicast UDP, but note that WSJT-X will only send
broadcast UDP datagrams on the loop-back interface, so all recipient
applications must be running on the same host system.
The reference UDP Message protocol applications are being extended to
be configurable with a list of interfaces to join a multicast group
address on. By default they will only join on the loop-back interface,
which is also recommended for any applications designed to take part
in the WSJT-X UDP Message Protocol. This allows full user control of
the scope of multicast group membership with a very conservative
default mode that will work with all interoperating applications
running on the same host system.
RIGCTRL is defined as a log channel for rig control messages and the
appropriate logger is made available to children of the Transceiver
class. Use Transceiver::logger() to access the logger.
Switched existing rig control QDebug messages to Boost logging.
where possible audio devices that disappear are not forgotten until
the user selects another device, this should allow temporarily missing
devices or forgetting to switch on devices before starting WSJT-X to
be handled more cleanly. If all else fails, visiting the Settings
dialog and clicking OK should get things going again. Note that we
still do not have a reliable way of detecting failed audio out
devices, in that case selecting another device and then returning to
the original should work.
Enumerating audio devices is expensive and on Linux may take many
seconds per device. To avoid lengthy blocking behaviour until it is
absolutely necessary, audio devices are not enumerated until one of
the "Settings->Audio" device drop-down lists is opened. Elsewhere when
devices must be discovered the enumeration stops as soon as the
configured device is discovered. A status bar message is posted when
audio devices are being enumerated as a reminder that the UI may block
while this is happening.
The message box warning about unaccounted-for input audio samples now
only triggers when >5 seconds of audio appears to be missing or over
provided. Hopefully this will make the warning less annoying for those
that are using audio sources with high and/or variable latencies. A
status bar message is still posted for any amount of audio input
samples unaccounted for >1/5 second, this message appearing a lot
should be considered as notification that there is a problem with the
audio sub-system, system load is too high, or time synchronization is
stepping the PC clock rather than adjusting the frequency to maintain
monotonic clock ticks.
Enumerating audio devices with QAudioDeviceInfo::availableDevices()
takes a long time on Linux with pulseaudio. This change only
enumerates up to the selected device when configuring and only
enumerates the whole list when the Settings->Audio tab is current.
This change also warns with a message box when Tx is started with no
audio output device configured.
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 enforces an audio input device in the settings dialog since we
can't do anything without an input device. A nil audio output device
is allowed with a warning.
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.
the decoders. Also, an experimental change to the FT4 decoder to base
AP decoding passes on 4-symbol block detection instead of single symbol
detection. This provides about 1 dB improvement on the AWGN channel.
Sensitivity changes on other channels are TBD.
This is a check box option in "Settings->Colors" rather than new
highlighting types so un-worked field highlighting and un-worked grid
square highlighting are mutually exclusive. The check box state can be
changed at any time, no log rescanning is necessary, and subsequent
decoded message highlighting will be according to the check box state.
The Status(1) message acquires the new fields Frequency Tolerance, T/R
Period, and Configuration Name. The Rx DF, Tx DF fields become
unsigned (this should be a benign change which is just for correctness
as -ve values have never been possible).
The Close(6) message becomes bi-directional allowing external
applications to gracefully close down WSJT-X instances.
A new message SwitchConfiguration(14) is provided that allows an
external application to switch the current configuration of a WSJT-X
instance.
Another new message Configure(15) is provided to allow external
applications to adjust some key parameters like the mode and submode.
See the NetworkMessages.hpp header commentary for full details. The
UDPExamples/MessageAggregator reference application has been updated
to be able to exercise all of the above changes.
Note that this commit enforces stricter checking on the
"Settings->Reporting->Allow UDP requests" option, which must be
checked before any state changing incoming messages to a WSJT-X
instance are processed.
Re-enabling the WSJT-X i18n facilities. This allows translation files
to be created for languages that are automatically used to lookup
translatable strings. To enable a new language the language name must
be added to the CMakeLists.txt LANGUAGES list variable in BCP47 format
(i.e. en_US, en_GB, pt_PT, ...). Do one build with the CMake option
UPDATE_TRANSLATIONS enabled (do not leave it enabled as there is a
danger of loosing existing translated texts), that will create a fresh
translations/wsjtx_<lang>.ts file which should be immediately checked
in with the CMakeLists.txt change. The .ts should then be updated by
the translator using the Qt Linguist tool to add translations. Check
in the updated .ts file to complete the initial translation process
for that language.
To aid translators their WIP .ts file may be tested by releasing
(using the lrelease tool or from the Linguist menu) a .qm file and
placing that .qm file in the current directory before starting
WSJT-X. The translations will be used if the system locale matches the
file name. If the system locale does not match the file name; the
language may be overridden by setting the LANG environment variable.
For example if a wsjtx_pt_PT.qm file is in the current directory
WSJT-X will use it for translation lookups, regardless of the current
system locale setting, if the LANG variable is set to pt_PT or pt-PT.
On MS Windows from a command prompt:
set LANG=pt_PT
C:\WSJT\wsjtx\bin\wsjtx
elsewhere:
LANG=pt_PT wsjtx
