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 piconet interactions that didn't fill me with joy. I suppose I could run a virtual USB cable across the network using "USBip Hot Plug" between two Raspberry Pi's and have a go, and I might still try that.

Ultimately I didn't find anything that came close to a real solution to fix my audio issue, but this morning it occurred to me that essentially the thing I was looking for needed to be two-way, since if I'm going to make this work, Bald Yak would need to deal with a received signal as well as a transmitted one.

For reasons I don't understand, let's call it my ah-ha moment, I imagined a picture of blocks scattered about, each doing their own thing and signal lines travelling between them. The phrase "peer-to-peer" came to mind and I started searching. I came across a tool called "SonoBus", a cross platform open source application that allows users to create a distributed network of audio users, specifically supporting both recording and playback. Looked excellent, right until I discovered that the last release was three years ago and there were 178 pending issues and 17 pull requests. Mind you, looking at it again now, there are branches that were updated less than three months ago, so it's still being developed and ultimately why I'm mentioning it.

I toyed with the notion that I/Q signals are essentially two channels per sample, much like an audio stream is a left and right channel, so there was the possibility of shoehorning a radio signal into this platform, right until I realised that I need to still do weird stuff like change frequency, mode and perhaps antenna and the like.

So, we're back to square one, but with it comes an understanding that part of Bald Yak is going to need something that does peer-to-peer signal streams.

That gives me a description of what it needs to do. Essentially pipe data across the network between devices. It should be lightweight, offer the choice of lossless or lossy streams, since a command needs to be guaranteed to get to the other end, but you might decide that audio doesn't. It should be cross-platform, needs to be network and device agnostic, should follow Unix philosophy where programs do one thing and do it well, work together and handle text streams, because that is a universal interface.

Mind you, I suspect that a text stream in this case is going to be a byte stream, but that's beside the point.

It might transpire that such a thing already exists, "netcat" comes to mind for example, which if true would progress my efforts one step closer.

All in all, it's been a good week.

I'm Onno VK6FLAB