Virtual Audio Cable Setup for Ham Radio Digital Modes
Digital modes depend on audio moving cleanly between programs. With a conventional transceiver, the audio travels through a USB sound card or an interface cable between the radio and the computer. But many modern stations do not work like that. An SDR receiver produces its audio inside the computer, a remote station delivers its sound through software, and some operators want a decoder, a recorder and a skimmer to listen to the same signal at once. In all of those cases a virtual audio cable does the job: a small driver that creates a pair of virtual audio devices in the operating system, so that audio played into one end comes out of the other. This guide explains how it works, shows a reliable step-by-step setup for a typical receive chain, covers the sample rate and level settings that cause most failures and lists the problems you are most likely to meet.
What a Virtual Audio Cable Is
A virtual audio cable is software that behaves like a physical audio lead. The developer of one widely used example, VB-CABLE, describes it as a virtual audio device in which all audio coming in at the cable input is simply forwarded to the cable output. To the operating system it appears as two devices: a playback device, which the first program uses as its output, and a recording device, which the second program uses as its input. Nothing leaves the computer and nothing needs a sound card; the audio is passed from memory to memory.
The same page shows that this particular product is distributed as a driver pack for Windows, with packages stated to cover versions from XP to Windows 11, and a separate driver package for macOS. It is described as donationware, with additional virtual devices offered to those who donate. The details of any such product change over time, so read the current page before you download. The principle, however, is the same for every virtual cable on every system, and on Linux the equivalent is a virtual sink or loopback device created by the sound server.
Typical Uses in a Ham Shack
- SDR receiver to decoder. The SDR program demodulates a signal and plays the audio into the virtual cable, and WSJT-X or fldigi listens to the other end of the cable. This is the most common use. Our guide to SDR for ham radio explains how SDR programs and receivers differ.
- Remote station audio. Software that carries audio from a remote radio plays it on the local computer, where a virtual cable sends it to the digital mode program.
- Decoder to recorder or second program. A cable lets you record the audio that another program plays, or feed a CW decoder alongside a logging program.
- Two decoders on the same signal. A split with a second cable, or a program that can send audio to two devices, lets you try two decoders on the same audio at once.
A Receive-Only Setup, Step by Step
The following sequence is for a Windows computer with an SDR program and a digital mode program. The same logic applies to other systems.
- Install the driver. Run the installer as an administrator and restart the computer when it asks. Without a restart the new devices may not appear.
- Check the new devices. In the sound settings you should see a playback device and a recording device with matching names. Do not make either of them the default for the whole system; that would send all system sounds into the cable.
- Set the SDR program’s audio output to the cable’s playback device.
- Set the decoder’s audio input to the cable’s recording device. In WSJT-X this is the input device on the audio tab of the settings window; the program’s own documentation, available from the WSJT-X project page, describes the controls.
- Match the sample rate. Set the cable device, the SDR output and the decoder to the same sample rate. For WSJT-X, 48 kHz is a common choice.
- Tune an active signal and check the level. The decoder’s audio meter should show a healthy level, not clipped and not at the bottom of the scale.
After this you should see decodes appear in the digital mode program as soon as it hears a signal in the passband of the SDR. If you are new to the digital program, the article on WSJT-X setup for FT8 explains the other settings, and the article on fldigi setup does the same for that program.
Transmit Audio: Two Cables Are Better Than One
If you also want to transmit through software, you have a second audio path: from the digital mode program to the transmitter. With an SDR transceiver that processes audio inside the computer, the digital program’s output goes into one cable and the SDR program takes it from the other end as its transmit input. Receive and transmit paths must be separate, otherwise audio can loop back and cause feedback or a runaway signal. In practice that means two independent virtual cables, one for each direction. Some products provide extra cables as additional virtual devices, and the Linux sound servers allow as many as you like.
Take extra care with the transmit direction. A misrouted audio path can send a loud tone into the transmitter or key it unexpectedly. Always test with a dummy load or with the power turned all the way down, and confirm the audio level on a monitor receiver or with the program’s ALC indication before you connect an antenna. The article on rig control with Hamlib covers the PTT and CAT side of that chain.
Settings That Cause Most Problems
| Setting | What goes wrong | What to do |
|---|---|---|
| Sample rate | Mismatched rates cause resampling, drift or no audio | Use the same rate, such as 48 kHz, in the cable, SDR program and decoder |
| Default device | System sounds leak into the decoder, or the program picks the wrong cable | Select the devices explicitly in each program, leave the cable out of system defaults |
| Audio enhancements | Processing changes level and spectrum | Disable enhancements and effects on the virtual devices |
| Exclusive mode | One program locks the device, a second cannot use it | Turn off exclusive access, or use a separate cable per program |
| Microphone privacy | The operating system blocks the recording device from applications | Allow desktop applications to access the microphone in the privacy settings |
| Buffer size | Dropouts, or too much delay for time-critical modes | Increase the buffer slightly if there are clicks, keep it small for latency |
Levels and Timing
Virtual cables carry digital audio, so there is no hum or noise from analogue wiring, but levels still matter. If the SDR program plays at a very low level, the decoder sees a signal near the bottom of its dynamic range; if the level is too high, the audio can clip and the decoder performance drops. As a guide, the level meter in WSJT-X should show a reading in the middle part of its scale for an average noise floor, with strong signals still well below the top. Adjust the volume in the SDR program first, and use the Windows volume for the cable device only for fine adjustments.
Timing is the other concern. Weak-signal modes such as FT8 depend on accurate computer time, not on the audio path, but delay in the audio chain can matter for other uses, such as CW break-in or a voice keyer. For decoding it is rarely a problem. If you notice that your decoder shows signals later than a second receiver does, check the buffer sizes, and make sure the computer clock is accurate.
Linux and macOS Equivalents
The idea is the same on every system, but the tools differ. On Linux the sound server can create a virtual output that behaves as a cable: you load a null or loopback device, and its monitor appears as a recording source that other programs can select. Graphical patch tools make the connections visible, which is convenient when several programs are involved. On macOS the operating system has no built-in equivalent, so a loopback driver is installed, and it then shows up in the audio device lists of the applications just like a physical interface. In both cases the checklist is unchanged: choose the devices explicitly, match the sample rate and keep receive and transmit paths apart.
Recording and Analysing the Audio
A virtual cable is also an easy way to capture what the decoder hears. Point a recorder at the same cable, or use the recording feature of the SDR program, and you get an audio file that you can replay later. That is valuable for testing a decoder setting, for studying a weak CW signal that was almost readable or for demonstrating a problem when you ask for help in a forum. Keep an eye on disk space, because uncompressed audio files grow quickly, and remember that recordings of other people’s transmissions are subject to the rules and privacy expectations of your country.
Choosing Names and Keeping the Setup Tidy
Once you have more than one virtual device, the default names quickly become confusing. Write down which cable carries which signal, and if your system allows renaming devices, give them meaningful names such as receive audio and transmit audio. Keep a short note of the sample rate and the program settings that worked, so that you can rebuild the chain after an operating system update or a new computer. It is also wise to start the programs in the same order every time, first the SDR program, then the decoder, then the logger, because some programs scan the available audio devices only when they start. If a device is not found after a restart, closing the program and opening it again is often all that is needed.
Finally, test the whole chain on a known good signal before a contest or a scheduled net. A time signal station, a beacon or a strong FT8 signal makes a good test, and ten minutes of checking beforehand saves an evening of frustration.
Troubleshooting
- No audio reaches the decoder. Check that the SDR program’s output and the decoder’s input point to the two ends of the same cable, and that the SDR is actually playing audio.
- Audio is distorted or robotic. A sample-rate mismatch or a buffer that is too small. Match the rates and try a larger buffer.
- A howl or echo. A feedback loop: the output of one program is also routed back to its own input. Remove the loop and use separate cables for receive and transmit.
- The device disappears after an update. Reinstall the driver as an administrator and restart.
- System sounds appear in the decoder. The cable is set as the default device. Return the default to your normal speakers.
The Bottom Line
A virtual audio cable is a simple tool that makes software-only radio stations possible: audio goes from one program to another without a sound card or a lead. Install the driver properly, choose the devices explicitly in each program, match the sample rate everywhere, keep receive and transmit paths on separate cables and never leave the cable as a system default. Test the transmit path with a dummy load before you connect an antenna. With those habits the setup is reliable, and you can concentrate on the signals instead of on the plumbing.
Frequently Asked Questions
What is a virtual audio cable?
It is a driver that creates two linked audio devices, so audio played into one comes out of the other. It lets two programs on the same computer exchange sound without a physical sound card or cable.
Which sample rate should I use?
Use the same rate in the cable, the SDR program and the decoder. A rate of 48 kHz is a common choice for WSJT-X, but the key point is that all the settings agree.
Do I need two cables for transmit and receive?
Yes, if you want to transmit through software. Using one cable for both directions risks feedback loops and unexpected transmissions, so use a separate cable for each path.
Why is there no audio in WSJT-X?
Check that the correct cable end is selected as the input, that the SDR program is playing to the other end and that the operating system allows applications to use the recording device.
Does it work on macOS and Linux?
Yes, with different tools. Some vendors offer a macOS driver, and on Linux the sound server can create virtual sinks and loopback devices that serve the same purpose.
Can a virtual cable add noise to my signal?
It does not add analogue noise, because the audio stays digital. Problems come from level, clipping, resampling and buffer settings, not from the cable itself.