As the drivers for the SDRPlay hardware are NOT open source, they may/may not be supported by ka9q-radio at a given time.  If you do need SDRPlay support, versions of ka9q-radio from mid 2023 may do so (these versions predate a major re-work of the code to improve efficiency).  There may be forks of more recent versions of ka9q-radio that do support the SDRPlay hardware, but you'll probably have to look around for them.

Workarounds:

• Maintain backups of configuration files as you modify them.
• Use "alternate" versions of configuration files with different names.  This may often be using the "-f" parameter (on "airspyd", "rx888d", "sdrplay").
• If you are running some of these programs as a service, note that the ".service" file may also be overwritten as well.

This issue is understood by the author and is on the "to-do" list to fix.

As noted by the author of ka9q-radio in the /docs/FFTW3.md file there are issues with how the FFT "wisdom" file (a file that contains optimizations of the Fast Fourier Transform for your computer hardware) created/accessed/used - please read this document if you have not already done so.  FFTW3 is the heart of "radiod" - the main program that does the "magic" of ka9q-radio.

Somewhat related, there are other utilities that use FFTW3 that may have issues with using an existing FFT wisdom file.  For example, the "modulate" utility will always create a new wisdom file when it is started (causing a delay of between 5 seconds and several minutes - depending on your processor speed).  Normally, such a wisdom file is created only once, but this program doesn't see to "know" about the existing wisdom file and simply recreates it every time it's invoked.

The best that can be done is set the squelch thresholds to "0" or a negative number.  The documentation mentions setting the parameter "squelch-open" to something like -1000, but this only seems to work for synchronous AM reception, not FM/PM.

What this means is that if you are using the pm or fm demodulator, the squelch will always be enabled as the defaults are 8 dB SNR to open the squelch and 7 dB SNR to close it (e.g. 1 dB hysteresis).

Remember:  Unless a signal is present on the frequency and the squelch is open, radiod will not even produce a multicast stream.  If, for example, you are using the "control" program and have defined, say, ten FM frequencies to be used, you will see nothing at all from any of the ten virtual receivers until/unless there is a signal from one of them - and even then, you'll see data from only those frequencies with signals present.  Please note that the muting of the PCM data stream when the squelch is close is NOT a bug, but this behavior - and the inability to completely disable the squelch (for testing, measuring SINAD of a receive system, listening for vestiges of extremely weak signals) - can be initially confusing.

If an analysis is done, it seems to "kill" the virtual receiver.  Example:  Using "radiod@hf.conf" with the rx888d, if one does an FFT analysis on the 5 MHz WWV, that particular multicast sub-stream will stop and not restart.  (Ubuntu 22.04)

If too many bins are requested using the configuration mentioned above, "radiod" throws a segment fault and stops.  (Ubuntu 22.04)

Example:  Using "radiod@hf.conf" with the rx888d will always cause this.  (Ubuntu 22.04)

While the "M" command in monitor will mute all current sessions, new sessions (e.g. those that appear after the "M" command has been issued) will NOT be muted.  If you are running monitor and have a speaker turned up, but have all sessions muted, you will still hear audio from a new session when it comes up.

At the time of writing (20230614) the "rtlsdrd" program uses only command-line arguments, not a .conf file.  It also does not have a related ".service" file.

At the time of writing (20230614) the "rtlsdrd" program does not support the direct "Q" input for reception on HF.  This is a hardware feature present on many RTL-SDR dongles (e.g. "RTLSDR Blog V3") that allows reception from <1 MHz through 30 MHz by bypassing the onboard Raphael R820T tuner.  This capability is useful, despite the limitations of the RTL-SDR (e.g. 8 bits, no AGC, need for filtering to avoid alias responses).

At the time of writing (20230614) the "rtlsdrd" program does not support the setting of manual gain on the R820T converter.  

It is useful to set the gain of the RTL-SDR manually in the following scenario:  In many metropolitan areas, there can be repeaters with signal levels that are >-50 dBm.  As the AGC action of the RTL-SDR will naturally set the gain to maximum in the presence of strong signals, when a signal greater than approximately -65 dB appears in the passband, the receiver will briefly overload prior to the AGC action occurring.  This causes two effects:

• All signals being received will be briefly disrupted due to overload.  For voice monitoring, this causes an audible "click", but for AX.25 packet operation, this will probably cause the loss of the entire packet.
• Weaker signals will seem to appear and disappear depending on the current AGC-derived gain setting, the depth of gain reduction due to AGC action and the strength of the weak signals.  This issue is unavoidable due to the limited dynamic range of the RTL-SDR's 8 bit A/D, but a fixed gain setting would provide consistency.

It would also be useful to limit how high the AGC gain could go in the absence of other signals.  In practice, the manual gain could be set for the user's RF environment emperically - by observing when the strongest local transmitters (e.g. repeaters) are active and observing the A/D's peak "dbFS" reading using the control program.