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.
