Audio issues with wfview on windows

After a week of fiddling I have concluded that the weakest aspect of this really wonderful software is by far how it does or does not handle audio. Of some 10 hours that I tried to use wfview in that week I have burned probably 5 hours trying to get audio to work daily… Once its working its fine for the day… but the next day … is not guaranteed. Its always something to do with the audio input or output in the wfview server or remote.

Plugging in headphones at your PC that runs the server to listen to something like youtube seems to affect the wfview sound input and output “sometimes”. Usually when you dont suspect it.

For example I listen to youtube on usb headset at the server… then later on turn on desktop wfview and leave the office expecting to be able to access server on wfview remote and hear radio audio on the laptop. Somedays it works instantly on the remote laptop speaker, other days no amount of fiddling makes it work.

If I plug a USB headset in the W11 laptop while the audio IS working on the speaker, sometimes it will work other times not. Changing the setting panel in the remote is not reliable way to get it to work. Then another day I forgot my usb headset and borrowed an analog headset which I plugged into the headset jack on the side of the laptop… It worked ok… but then after unplugging it no amount of fiddling returns the audio to the loudspeaker on the laptop.

I have worked with PCs regularly since windows 98 and generally can install and run just about any software without much ado. In this case I can only conclude that something is not 100% thought out in the audio department of wfview.

If there is a pattern to this above issue I dont yet see it.

The other issue that stands out in my mind is that it seems that wfview does not provide good feedback on the state of the server to a user at the remote. For example you might think you are connected because the disconnect from radio message is at the bottom of your remote… but you are not… If you are connected and push to transmit… the button changes colour to confirm you pushed it but you dont have any guarantee the server received it or any indication if it did or did not. If there is handshaking I dont see any reliable indication of it in the remote. Perhaps an LED should light on the transmit button to show that the server has sent a confirmation to the remote that the radio is in transmit mode… rather than the remote making the assumption the radio is in transmit mode just because its button was pushed.

That said I would be satisfied with this app if only I could figure out the pattern with the audio driver issues. My desktop server and remote laptop pc is set to windows default modes. Enhanced audio is off in both. No other apps on the either pc have any audio issues or issues communicating… only wfview. Everyone should know that the days it worked flawlessly I really really enjoyed it.

What do you have the Audio Input/Output set to in Wfview? You might do well to use some intermediate software like Voicemeeter Banana, which is commonly used with SDR rigs and digital modes. You can then set various hardware input/output devices like headsets and headphone jacks.


wfview doesn’t have any control over your audio drivers and devices. That’s all up to the OS and the end user.

Make sure you have the audio configuration that you want and devices connected prior to opening wfview. This is the only way to get consistent behavior.

de W6EL

In line with what Elliott said, using a virtual audio mixer can let Wfview always see the same audio connections, it won’t see changes to the hardware input/output devices. For instance, with the VM Banana you’d set the audio devices Output/Input in Wfview to always be “Voicemeeter AUX Virtual” Input/Output. WSJT-X (or fldigi or whatever) would use the “Voicemeeter Virtual” Input/Output (no “AUX”), and the hardware devices would be set to whatever you have and be muted if not in use.