Raspberry Pi Lan Remote Setup
I am lucky enough to have an outbuilding with mains power, which is the obvious place for the radio gear. I have used FLdigi successfully for digimodes with this setup, running it on a Raspberry Pi in the shack over WiFi. The Pi is a fabulous little shack computer, particularly if you aren’t in front of it, because it is low-power, does most of what you want with radio software-wise, and is pretty much expendable. I am a big fan of the Pi. I used FLDigi with FLRig.
You can get FLDigi to control the rig directly, and on Windows using FLrig was a world of hurt for me, but on linux FLrig was well-behaved with Hamlib, though I had to compile it because PTT didn’t work on my ancient steam-driven FT897 with the Raspbian version which was old. I use FLRig CAT control rather than the digital VOX on my G4ZLP MiniPro interface because that doesn’t send OS dings and bongs to TX1.
The trouble, of course, with being in a different building from the rig is you can see the data coming in on the waterfall fine, but you can’t hear anything. The rest of your family, of course, may regard that as A Good Thing, but it precludes you from using voice, and makes the experience just that little bit less real. I would like an audio path. Other radio amateurs solve this using Skype or TeamViewer, and there are hardware solutions. Indeed MFJ make a remote solution based on a Pi called RigPi for 350 sods which looks dandy, but £350 is pushing it a bit for a box and an audio interface, although probably when I factor in my time mucking around I should have dropped the cash ;) From the reviews on eham you still get to muck around ;)
Running audio over an ethernet LAN is a world of hurt, and even more on wifi. Some people remote their stations over t’internet. I personally don’t get that, if it needs the internet then why not use Zoom/Zello/Network Radios, but each to their own. From previous experience a latency of 200ms is livable with for half duplex voice, but you have to work around that. I wanted less. However, the first requirement I had was to hear the digimode signal. For that a latency of 1 second was OK, and initial experiments showed icecast and darkice on a Pi2 would work OK to a browser. It had a latency of about 2 seconds, and was receive only
Mumble
Mumble is a VoIP solution used by gamers. Their tagline is
Mumble is a free, open source, low latency, high quality voice chat application.
What they mean by low-latency? Buffering seems to be < 50ms, using Opus codec on a LAN in my case. There’s a PC Mumble client, so I can listen using my Windows PC to my radio, and the server can cope a couple of channels so I can listen to different radios when I get that far. It runs on a Pi. Indeed in my case the TX client and the server run on the same Pi4 that FLDigi/FLRig run on. The great thing about Mumble is there’s no Cloud in it. I don’t like Cloud. If my radio path depends upon some SaaS then roll with it, just use Zoom/Zello.
Mumble works well if combined with FLrig rig control. I set it to send audio all the time, and I will send my PC to send audio all the time. I will use FLRig’s PTT control to actuate the transmitter - it doesn’t matter what garbage I send to the mic input, it isn’t sent until I press PTT on FLrig.
I will allocate another Pi specifically for Mumble for voice - going in through the mic input of the FT897. Currently I have the Pi going in through the data port on the back, which is only enabled for the DIGI mode, which is always USB. You have to go in through the Mic jack to use LSB/USB/FM/AM, as the FT897 is a shack in a box I may use it on VHF as well. However, Mumble on the data Pi bridged over the input from the Data jack lets me listen to the data signal coming in. Which is cool.
Audio is tough on Linux
Raspberry Pi have moved to using PulseAudio to manage sound connections. Mumble only works 2 if you select the system ALSA which then reroutes though PulseAudio, which routes back through true ALSA. I have no idea why. I had nearly given up on using mumble until I discovered that wrinkle. FLDigi can use Portaudio (WTF?) or Pulseaudio fine, which is why Mumble not working with Pulseaudio did my head in
(Rant) Linux audio is desperately borked IMO
Until December 2020. the Pi used ALSA as its audio subsystem. Let’s get the inside lowdown from the Pi lot.
Audio on Linux is really quite complicated. There are multiple different standards for handling audio input and output, and it does sometimes seem that what has happened, historically, is that whenever anyone wanted to use audio in Linux, they looked at the existing libraries and programs and went “Hmmm… I don’t like that, I’ll write something new and better.” This has resulted in a confused mass of competing and conflicting software, none of which quite works the way anyone wants it to!
Until now they used ALSA, and the upside is it generally works. The downside is that only one program at a time can access the sound card. In the past the Pi was gutless enough this wasn’t an issue, but now it is possible to run more than one program on a Pi at the same time, and for this to make sense. I started down this track because I have FLrig and FLDigi at the shack, and remote to it using RDP from the house. That means I don’t get to hear the radio. Some people use Mumble to remote the audio down the LAN. It would be nice to hear what’s going on, so I favour that. Audio needs to go to Mumble and to FLDigi at the same time. You wouldn’t think twice about expecting that to work on Windows3, but on linux you can do just about anything. If only you were smart enough to know how, and most of us aren’t. As Pi go on to say
PulseAudio deals with all of this. It’s a piece of software that sits as a layer between all the audio hardware and all the applications that send and receive audio, and it automatically routes everything to the right places. It can mix the audio from multiple applications together, so you can hear VLC at the same time as YouTube, and it allows the output to be moved around between different devices while it is playing. It knows how to talk to Bluetooth devices, and it greatly simplifies the job of managing default input and output devices, so it makes it much easier to make sure audio ends up where it is supposed to be!
The good news for Raspberry Pi users is that, if we’ve got it right, you shouldn’t even notice the change. PulseAudio now runs by default, and while the volume control and audio input/output selector on the taskbar looks almost identical to the one in previous releases of the OS, it is now controlling PulseAudio rather than ALSA. You can use it just as before: select your output and input devices, adjust the volume, and you’re good to go.
They didn’t get it right, IMO. Amateur radio users tend to need audio in as well as out, in practice that means using a USB soundcard, and turning off the internal output only card. That seems to mean It makes it much easier to make sure audio ends up at /dev/null rather than It makes it much easier to make sure audio ends up where it is supposed to be!
As a temporary solution I have found that running ssh into the box on a terminal session as the Pi user and running
alsactl init
and only then running RDP to the GUI works serviceably well. It’s not good, it’s not clever, and one day it may not be necessary, but life is too short to try and make Pulseaudio behave. The developers show their outstanding arrogance in Whats Wrong with System Mode which basically says that because there might be multiple users on the system at the same time it’s a terrible idea to run the single sound system on this single computer at startup, just in case one of the multiple users Alice might hear that another user Bob has a fondness for country and western, when his work persona says he likes thrash metal. Well bite me. Most Linux systems which run audio have only one user at a time IMO ;) This is not some Big Iron Mainframe or even a Sun Sparc. It’s a Raspberry Pi FFS… Purity be damned. The (l)user is always wrong, eh guys?
-
if you set it up right in FLDigi with PTT tone to the right channel the interface works well and is a great nice to have. ↩
-
Q1 2021, Raspberry Pi 4. Pulseaudio seems particularly finicky on a Pi4, on a Pi2 it sort of just works, except Mumble still puts out silence if selecting pulseaudio. Maybe they will fix this in a few months time. ↩
-
We should note that FLDigi is a load of hurt on Windows in mine and G5FM’s experience if you have more than one sound card, because they all tend to be called Generic Sound Device and tend to swap positions after an update. I suspect this pathology which seems specific to FLDigi is because it comes from the Linux world and uses something called portaudio which was supposed to be cross platform. It is, inasmuch as it replicated Linux’s ratty audio performance on Windows. ↩