Bald Yak 22: Peer to Peer Radio

Foundations of Amateur Radio

After spending a full day banging my head against a wall, again, this morning I hit on a phrase that hadn't occurred to me, "peer-to-peer audio" and with it came an insight into the problem I've been working on since I conceived of Bald Yak. In case you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It's called Bald Yak because by the time I'm done, the Yak is likely well and truly shaved.

While it might seem superfluous rehashing my frustrating day, I think it helps to describe more fully what I'm trying to achieve, so bear with me.

It started with me needing to have music to listen to. I normally stream something off the Internet, "SBS Chill" if you're interested, but having a shower thought, it occurred to me that I might create a spreadsheet of the things I could hear via RF in my shack. It's been a while since I was on any frequency other than the local VK6RLM repeater where I host F-troop, and I wanted to get back to doing some more hands-on radio.

After listening to "ABC Classic FM" on my amateur radio transceiver, I scanned up and down the FM broadcast band and heard plenty more stations. The audio wasn't cutting it, I mean, who wants to listen to Claude Debussy or Wolfgang Amadeus Mozart performed in glorious mono?

I thought of using an RTL-SDR dongle to do the tuning and listening, the tool "rtl_fm" is perfect for the job. One problem. How do I get the audio from the device with the dongle, to my ears? I suppose I could plug in a pair of speakers and have at it, but I'm not alone and my office is central to the house, so anything here is heard everywhere. Headphone cables are too short and my antenna is also on the opposite side, so challenging.

Mind you, I already bridged this gap once with RemoteRig, which essentially replaces the serial cable between the head and body of a radio with a network connection, for me that's across the room, but it could easily be across the Internet.

All of this is complicated by my current computing set-up. I'm typing on a keyboard connected to a MacBook in turn connected to an external monitor. That monitor is also connected to a Debian Linux computer running Proxmox where my old workstation is running in a virtual machine and in the process of being resurrected. It also runs several other virtual machines where I'm running GNU Radio in a Docker container.

One noted absence from that setup is audio.

Right now, I record my podcast audio onto a Zoom H5 handheld recording studio in my wardrobe, then transfer the audio file to my old workstation where all the scripts live to make my podcast live. I edit the audio by launching Audacity on the Mac and opening that file across the network. I hear the editing through the Zoom H5 re-connected to the Mac as a sound-card. Otherwise audio is non-existent, not excellent for listening to radio or anything else for that matter. Ideal, no, not even close, but that's just one example of still recovering from my hardware crash over two years ago now. Mind you, audio was already challenging with software running inside Docker, but that's a whole other thing.

I spent the day looking for ways to get audio across the room. I played with "ffmpeg" and RTSP streaming, only to discover that you need to install and configure more software in the form of a server, which is no longer included with ffmpeg. Also, apparently for reasons best understood by Apple, QuickTime Player no longer supports RTSP URLs, so go-figure.

I looked at "pipewire", apparently needs a GUI to configure it, needs extra software installed and doesn't appear to be readily cross-platform, though I didn't dig too deep once I discovered the GUI requirements, I might come back to it.

I explored running a Bluetooth audio server on a Raspberry Pi to stream audio to my headphones, much like I'm listening to right now, but that too seemed cumbersome, and included all manner of pairing, trusting and ad hoc pico