When the stay at home orders that resulted from the outbreak of the COVID-19 pandemic went into effect, the Kitchener Waterloo Amateur Radio Club (KWARC) was forced to start holding our meetings remotely.
Being a radio club and having some members who suffer from unreliable internet access at home, we were loathe to move proceedings entirely to Zoom, and started holding club meetings on our VHF repeaters. In time, we realized that some of our members did not have access to a VHF radio at home or were out of range of our repeaters, and would be better served by a Zoom call.
In an effort to serve all club members equitably, we decided to combine the two technologies. Meetings would be held primarily on VHF, but we would pipe the audio from the meetings into Zoom, allowing members who couldn’t get on the air to at least listen to the proceedings.
v1: The Hardware Based Solution
Our initial stab at a solution was hardware based. One of our club members, Patrick VA3PAF, put a spare VHF radio and his wife’s smartphone into a box, logged into the Zoom meeting on the smartphone, recording the audio from the radio and sending it directly into Zoom.
This approach worked well, so long as the box was far enough away from Patrick’s primary radio and other sources of interference so as not to be swamped with noise. Because it wasn’t monitored during meetings, we had a couple of problems with the phone’s battery dying or Zoom crashing that caused the audio signal to drop until Patrick could troubleshoot the problem.
v2: The Software Based Solution
In an effort to improve on the hardware-based solution, I started digging into software solutions. I realized that my primary VHF radio, a Kenwood TM-281, features a 3.5mm output jack on its back panel. I purchased a short 3.5mm male to 3.5mm male audio cable, and plugged the radio’s output into my Scarlett 2i2 audio interface. This setup allowed me to record any signal received by my radio on my computer, or to pipe that audio directly into Zoom.
After a little bit of testing, I realized that this setup still had a problem – it was only capable of recording audio that came out of the radio, and that audio cuts out any time I transmit. This meant that people listening on Zoom could hear everything that was happening on the repeater, except for my transmissions.
The fix for this problem was to introduce a software mixing solution. My primary computer is a Windows 10 machine, so I chose to use VB-Audio VoiceMeeter Banana, a donationware application that allows you to mix the audio from two or more devices together in software, and send the resulting signal out to some other audio device.
This piece of software was a total game changer for me. It allowed me to mix my webcam’s microphone in with the signal from my radio, in theory allowing the folks on Zoom to hear a perfect re-creation of what was actually happening on the repeater.
One problem remained, and that was figuring out where to send the audio to. By default, the only output devices that are available on a Windows computer are physical ones. I could send the resulting mix out to my laptop speakers, or to the output of my audio interface, but I couldn’t send it to Zoom, because Zoom is designed to listen to audio inputs.
Once again, the folks at VB-Audio came to the rescue, this time with VB-CABLE Virtual Audio Device, a software audio device that presents a virtual audio input device that is connected to a similarly named virtual audio output device via software. I could configure VoiceMeeter Banana to send the audio mix to the CABLE Input virtual device, and then tell Zoom to use the CABLE Output virtual device as a microphone.
Troubleshooting Choppy Audio
The setup described thus far worked great for the first year and a half of online KWARC meetings. One evening, I turned on my VHF radio, logged into Zoom, started the audio feed, and was immediately inundated by complaints from the folks listening on Zoom, all of whom were telling me that the audio was choppy.
I set about tweaking all of my audio settings, checking and double checking that everything was configured correctly, that none of the audio signals were being over-driven, and testing the audio signal at various points in the pipeline. After a bit of digging, I found that the issue seemed to be caused by the VB-CABLE Virtual Audio Device.
If I piped the audio from VoiceMeeter Banana out to my laptop’s speakers, the audio signal was clear as a bell. If I piped it into the CABLE Input, and monitored the corresponding CABLE Output with Zoom or recorded it with Reaper, the signal was choppy and unlistenable.
Some furious googling led me to this forum post, where the OP described the exact issue that I was having, and noted that the solution was to increase the size of the WDM Buffer.
Whenever audio is piped through a digital device or piece of software, some amount of lag is added to the signal. This lag is caused by one or more buffers – essentially a queue of audio samples – the software does its best to keep some number of samples in the buffer at all times so that it can ensure smooth audio processing and output. If a buffer is bigger than it needs to be, more lag will be introduced; if a buffer is too small, audio will not always be available, and the result will sound choppy.
I dug into the VoiceMeeter Banana settings panel, and found that the default WDM Buffer size was 512 samples. I increased this to 1024 samples, and lo and behold, the problem was resolved!
