Wireless audio and remote rig control, part 2

This article is a brief report on a low-latency audio streaming setup using the Mumble software.

A previous article described remote control, via PC, of a commercial superheterodyne receiver, and streaming the audio from that receiver over wifi for reception at another nearby location. This allows placing the receiver and antenna in a high-signal area (outdoors on a balcony), while placing the listening PC in a convenient indoor location. The use of wifi means that no cabling is necessary between the outdoor PC and the indoor PC.

However, the previous article's solution (using ffmpeg, JACK, and VLC software) achieved a best-case latency of about 1-2 seconds. In other words, the time delay between the actual audio output at the outdoor receiver, and that same audio output being received, decoded, and played back by the indoor PC, was about 1-2 seconds.

I was successful in reducing the latency by using a low-latency voice-over-IP software package called Mumble. This post briefly describes the background, procedure, and results.

Background

I have an HF-capable RTL-SDR receiver (a small USB dongle plus a homebrew upconverter) that is controlled by a PC running the gqrx software on Linux. The RTL-SDR, the PC, and a broadband loop antenna are sited in a high-signal location, outdoors on a balcony.

By operating the gqrx software on the outdoor PC, it is possible to control the RTL-SDR hardware and instantly to receive any frequency within its reception range. Because I am using a broadband antenna in combination with a broadband HF upconverter, I can receive any HF frequency from 0-30 MHz merely by operating the gqrx software. Furthermore, the RTL-SDR has a wide reception bandwidth (maximum of about 2.4 MHz), and gqrx provides a graphical display of spectrum activity, making it possible to see at a glance all spectrum activity (i.e. all signals) within the reception bandwidth. This makes searching for signals an audio-visual activity rather than a purely auditory activity as with traditional radios that have a narrow-band IF filter.

However, it is inconvenient to be operating the PC outdoors on the balcony when I want to listen to HF signals with the RTL-SDR. Therefore, my goal was to remotely control the outdoor PC via wifi, and to remotely receive the audio via wifi from the outdoor receiver, for final listening on an indoor PC.

First attempt: rtl_tcp and too-high latency

The RTL-SDR is a software-defined radio that makes the I/Q (in-phase and quadrature) data directly available for processing in software. My first attempt was to stream the raw I/Q data directly over the network, using the rtl_tcp program on the outdoor PC. The indoor PC then received the data via wifi and processed the signals in the gqrx software. While this worked, it had two major problems:

1. Latency was very high, on the order of 5 seconds or more. This is simply due to the massive amount of I/Q data that is being sent over wifi. Tests with a sampling rate of 2.4 million samples per second -- where each sample is 2 bytes -- yielded unusably high latency and frequent gaps/stuttering in the audio on the indoor receiving PC. Reducing the sample rate to the minimum of about 200 kHz reduced latency and stuttering, but latency was still too high to be comfortable (2 seconds or more). Furthermore, reducing the sample rate also undesirably reduced the visible bandwidth in the software's waterfall display, negating one of the benefits of using a wideband SDR.
2. The gqrx software seemed to have some bugs when decoding network data coming in from rtl_tcp. When running gqrx on the indoor PC, I noticed odd spurious signals such as the same station appearing at two frequencies separated by only a few-tens-of-kHz offset. These spurious signals were not present when running gqrx on the outdoor PC to directly (not over wifi) decode the I/Q signals from the hardware dongle. Some related links describing similar problems are as follows: https://www.reddit.com/r/RTLSDR/comments/4ygu66/is_anyone_using_rtl_tcp_and_gqrx_successfully/ , https://github.com/csete/gqrx/issues/402 . According to the last link, a workaround should be provided in gqrx version 2.7, but the version included in my Linux distribution was 2.6.

Second attempt: Use gqrx UDP audio streaming

The gqrx software has the ability to stream raw audio over UDP. By streaming only the decoded audio with 48 kHz bandwidth, instead of the entire 2.4-MHz-wide reception bandwidth, I hoped to substantially reduce the network traffic and hence reduce latency and playback stuttering.

I ran gqrx on the outdoor PC, and configured gqrx to streamed the audio over UDP to the indoor PC. Also, a VNC server was run on the outdoor PC to share its screen over the network.

On the indoor PC, I ran a VNC client to be able to see the outdoor PC's screen and to be able to operate the remotely-running gqrx software. Then, I used the following command to play the audio (being streamed via gqrx) with minimum latency on the indoor PC.

nc -l -u 7355 | aplay -r 48k -f S16_LE -t raw -c 1-B 300000

The last parameter of -B 300000 specifies a 300 ms buffer. Reducing this buffer value reduces the latency, but then increases the chance of gaps or stuttering in the played back audio if the transmitting (outdoor) PC cannot deliver data quickly enough over the wifi network. Increasing this buffer value reduces stuttering but of course increases latency.

Unfortunately, even with 300 ms of latency, the audio would still sometimes stutter, indicating a lack of incoming data for playback. In other words, the streamed audio from gqrx still was overburdening my wifi network (which uses an old PC with two wireless network cards as a router).

Third and successful attempt: use Mumble voice-over-IP software

AG1LE describes how he configured Mumble for remote streaming of audio from an amateur radio receiver. I decided to try Mumble as well, reasoning that Mumble would be able to compress the audio before network transmission, leading to further reduction in network load and further reduction in latency.

The setup was as follows. On the outdoor PC, I used:

• VNC server, to share screen over wifi.
• The RTL-SDR USB dongle, connected to a USB port.
• gqrx software, which demodulates RF signals from the RTL-SDR and produces audio output directed to the PC's audio output hardware.
• A physical audio patch cable running from the PC's headphone output into the PC's microphone input.
• Mumble server software to accept Mumble clients and route voice (audio) data over the network.
• A Mumble client, taking voice (audio) input from the PC's microphone input. Mumble client was configured as follows:
• Noise suppression disabled (enabling it leads to an over-aggressive AGC-like action where slightly fading shortwave signals will be miscategorised as noise and completely suppressed)
• Transmission mode set to "continuous" (instead of "voice activity" or "push to talk")
• Compression quality (slider) set to middle position

On the indoor PC, I used:

• A Mumble client to receive the audio being transmitted by the outdoor PC's Mumble client.
• A VNC client to see the outdoor PC's screen and to operate the gqrx software.

The results were as follows:

• Latency was greatly reduced, to less than 0.5 seconds. It is possible to operate the remote (outdoor) PC via the networked VNC client, and to hear the corresponding audio changes (e.g. when a new frequency was selected in the gqrx software) on the indoor PC almost immediately. The low latency makes operation of the remotely-running gqrx SDR software feel responsive and real-time.
• Latency never increases over time, but instead stays at a very low level over the entire streaming session.
• Playback gaps/stuttering were almost completely eliminated.
• Audio quality is slightly degraded by the compression. The audio sounds somewhat "tinny". Mumble is aimed at voice chat and not high-fidelity reproduction. Nevertheless, the audio quality is perfectly acceptable for listening to shortwave AM broadcasts and amateur SSB and CW transmissions. However, for amateur data transmissions such as RTTY or JT65, it is likely that the audio compression could prevent decoding of the data on the indoor PC. If data decoding is necessary, it should be done on the outdoor PC, where the raw uncompressed audio is available.

Next steps

• Investigate how to eliminate the audio patch cable. gqrx is already decoding the data into digital form. By playing it back over the audio output, then physically routing this (with an audio patch cable) back into the audio input, we are introducing extra digital-to-analog and analog-to-digital conversion steps. It would be better to directly pipe the gqrx digital data into the Mumble server. However, it is not clear if this is easily possible. Using the JACK software might be an option to reroute the audio data streams, but JACK does not seem to work with gqrx. Pulseaudio also seems to have some capability for rerouting audio data streams.
• Investigate throttling (restricting) the amount of network traffic used by the VNC screen-sharing software. Although the network usage of the audio stream (from outdoor PC to indoor PC) is throttled by the Mumble client settings, the network usage of the VNC screen-sharing software (again from outdoor PC to indoor PC) is not throttled and therefore may be consuming too much network bandwidth, which ultimately could lead to network congestion and delayed or stuttering audio. By explicitly limiting the amount of network traffic that VNC is allowed to use, this could ensure sufficient bandwidth for low-latency, non-stuttering audio. The "trickle" command on Linux may be one easy way to achieve the bandwidth throttling. Alternatively, Linux firewall rules and traffic shaping might be used.
• Improve my local network infrastructure by upgrading my old wifi hardware to a dedicated hardware router (instead of a repurposed old PC) that supports the latest and fastest wifi standards. This might require also buying newer, faster wifi hardware (USB dongles) for the outdoor PC and indoor PC, because the built-in wifi hardware of the outdoor PC and the indoor PC might not support the fastest wifi standards.
• Investigate interfering wifi signals (caused by other nearby wifi devices not under my control) and plan location of my wifi hardware  (router, transmitting PC, receiving PC) accordingly. Possibly, add a second intermediate wifi router if needed.