Hi everyone, I’ve been working on this for a few hours and looked extensively through the previous threads but have not been able to find a solution.
I am trying to get audio to my computer from my 7300, but the audio in wfview is just pops and crackles when I try to connect remotely. Audio does not seem to be working on the host computer either.
-I get the same issue when the radio is connected as a host to a Mac running OSX 10.15 and a PC running windows 11.
-ALL functionality of the radio and waterfall work perfectly on wfview (even the signal meter and control buttons and knobs), but audio is the only issue.
-On PC, the sound meter within windows sound settings appear to be receiving the audio properly, as I can see what appears to be a normal audio level (I have to way to monitor what it sounds like though). I have confirmed that it goes up and down as I adjust the ACC/USB AF Output level on the radio.
-On Mac, audio works fine via USB - I have confirmed this with RumlogNG’s audio routing function.
-Adjusting the AF slider on wfview DOES adjust the volume on the radio itself via the internal speaker, but does nothing on the computer.
Radio settings:
-CI-V Baud rate: Auto
-CI-V Address: 94h
-CI-V Tranceive: ON
-CI-V USB REMOTE Tranceive Address: 00h
-CI-V Output (for ANT): OFF
-CI-V USB port: Unlink from [REMOTE]
-CI-V USB Baud Rate: 115200
-CI-V Echo Back: ON
I have tried:
-Adjusting various settings within wfview, and saving before restarting the program.
-I have confirmed that the sample rate in all devices is 48000
-I have adjusted the RX latency to many different areas on the slider. Nothing improved.
-Baud rates are 115200 on both the radio and computer(s)
-As I saw in another support thread, I checked whether the control, civ, and audio ports in the Server Setup window are being used by other applications on the host computer(s) by going into cmd.exe and Terminal on OSX. They are not, and everything appears to be set properly. Audio port is 5003.
-Have tried turning CI-V Echo Back ON and OFF. No change.
I finally got it working - after puttering around with 1.2e for a while I somehow got something configured to where it would immediately crash on startup. So I went back to 1.2d, and after experimenting with it I found that the solution was the audio codec on the client side. For some reason the only RX codec that works is LPCM 1ch 16bit. When I have a few minutes I will experiment with 1.2e to see if I can replicate the same issue and solution for anyone that has the same issue in the future. Thanks @roeland for your help.
I have experienced crashes in wfview sometimes during development cycles when there is an issue with the config file you made for the rig.
In linux you can rename or remove the config file and do all over. How that is done in windows/macos… I guess the same but not using those platforms really.
(I have the config in ~/.config/wfview/wfview.conf)
The latest version has some seriously big improvements with the code around the audio. If I were you, I would close wfview on both ends and zap (erase) the preference files and start again. Phil worked tirelessly on making sure we can support various sample rates and codecs, and the latest version is a pretty big leap for wfview.
On macOS, the “defaults” command in the terminal can be used to access the “org.wfview.wfview” preferences. You can back up the preferences first before you do it.
The log file should tell you what’s going on if you’re getting a lot of audio glitches. The latest version of wfview lets you select the audio back-end, and you will likely find that one audio back-end performs better than another. The “Audio System” can be selected under “Radio Access” for now (applies to client and server, but must be selected on each computer).
