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.
