I only recently started trying wfview 1.2e with partial success, but I switched to 1.5 when it was released. I experience the same problem with 1.2e and 1.5, but having the log file readily available in the 1.5 GUI is a great feature.
My use case is a Windows 10 laptop using wfview to connect directly to the IC-705 via wifi mainly for running WSJT-X. As such, my default wfview saved audio input/output settings are VB-Audio Cable.
When I first connect to the 705, I have no audio from the radio. However, I found that switching the wfview audio to the laptop’s built-in speaker & microphone gets the audio working on the laptop. Then I can switch back to VB-Audio Cable and voila - it works just fine and I can happily use WSJT-X with the 705. This back and forth switching is all done within one wfview session while disconnecting the radio connection between switching the audio settings I have to do these gymnastics every time I connect to the 705 with wfview.
Interestingly, I see the “Input No audio device was found. You probably need to install libqt5multimedia-plugins” message on the initial attempt to use VB-Audio Cable, but not the second (when successful).
I see that the audio device name has a copyright symbol in it, and I wonder if this could be related to a bug Phil is chasing down. The fact that it works on the second connect kind of suggests to me a similar issue, but I am not sure. I will wait for Phil to have a look.
Thank you for posting! And I’m glad you like the log in the GUI, it has made a good bit of difference for working on the code as well.
Also, have you tried using any of the other audio systems, such as Port Audio or RT Audio? They use different methods and might work better in your case. Just select them in wfview next to the audio device selectors, and then, please, make sure to re-visit the audio device selection menus “as our menu options have changed”.
Thank you, Elliott. I have tried PortAudio and RT Audio, but just very briefly. I had no audio with PortAudio, and RT resulted in very warbly sounds, but I did not explore changing any other parameters. QT worked right out of the box, so I just stuck with it. I will investigate Port and RT again to see if they can work.
In a different thread, I saw that Phil mentioned a new weekly build that seemed to address my scenario in this thread. With the new build, I still do not have audio upon startup, but I do see in the log that when the program did not find the audio output device, it tried to find the default device, but that failed.
Moreover, when I tried my workaround this time, I did not get audio when switching back to the VB Audio Cable. It looks like the program thought it did succeed, though. Interesting.
I notice that the audio input is being found correctly, but the audio Output device is called CABLE Input (not VB CABLE Input). I wonder if you have some corruption in your audio device configuration? It might be worth trying to remove/reinstall VB Audio Cable and NOT rename the devices?
I’m glad you mentioned the audio device names. I had renamed them to help reduce confusion about which one was going or taking to the radio. I removed & reinstalled VB Audio Cable, and now I’m back to the point where I do not get audio when starting up wfview (the latest weekly build), but my workaround of switching to built-in speaker and microphones and back to VB Audio Cable does work.
I’m getting similar behavior. After tinkering for a bit thinking I had screwed something up, it held together for a QSO on FT8 but now it’s failing. I noticed after my first QSO I wasn’t getting anything when I transmitted, restarted everything and now I’m getting the same log lines.
After a little more prodding toggling the audio in WFview with a disconnect/reconnect dance does seem to sort it out eventually without restarting anything, but the lifetime is short. This log should represent working, losing, fixing and losing input. Output stays up:
I was able to get PortAudio audio system working with VB AudioCable when launching wfview weekly build 20221001-11-24-08. VB Audio Cable was 4th in the audio output pull-down list, so that got me thinking if the problem happened only for the 1st entry in the pull-down list. I describe an experiment below. Interesting results - always a problem when launching wfview with the first item in the Audio Output list for each Audio System.
This behavior is reproducible for me, so I hope it is for others, too, to identify and resolve the problem.
Best,
Ron
—
Running weekly build 20221001-11-24-08 on Windows 10
QtAudio
2 items in Audio Output pull-down list
Cable Input (VB Audio Virtual Cable) is first
Realtek Speaker is second
No audio output when launching wfview with VB Cable Output in save settings.
I just upgraded wfview to 1.5 and would try the WLAN option for my IC-705. It didn’t work as expected with VB-CABLE. JDTX could decode the signal but failed to transmit. After struggling for sometimes , I realized that I actually need two virtual cables while free version of VB-CABLE has one only. To prove if my understanding is correct, I downloaded VAC Lite version which provide another “free cable” for my test. It does work. I have already made several FT8 contact “wirelessly”.
Huzzah! Version 1.55 finally resolves the problem I had with having my preferred audio settings (QtAudio with VB-AudioCable) working initially when launching wfview - no more workaround needed. That issue had persisted from 1.5 through 1.54.
Thanks very much for the continuing improvements to the code.
I have been having this same problem, it is very annoying to have to keep executing the workaround and even then it is very unstable and flaky. I am using wfview 1.50 with an Icom 705 with firmware version 1.32 and Windows 10.
How do I load Version 1.55 in Windows? The nightly builds don’t identify which version they are, and following the instructions to just drop the exe file in the same directory as wfview.exe does not work. I figured I needed to RENAME the downloaded nightly build to “wfview.exe” but it still won’t work. Says it is missing some dll’s and I may need to reinstall.
Do not rename wfview. The weekly and daily builds are named for the date they were created. Generally, you just want to pick the last one made (which is at the bottom of the list of exe files). Save the exe file somewhere on your PC, perhaps the Downloads folder or Desktop folder. Move the downloaded file, keeping the name it has, to wherever your existing wfview.exe is stored. Perhaps that is c:\program files (x86)\wfview\. You’ll have to check.
If you have missing DLL files, please check the daily or weekly build folder, the DLL files should be near the top of the listing. Place those DLL files in the same folder as wfview.exe.
This process is necessary because we have added some features which require new libraries, and with windows, this is the least obtrusive method of instillation.
When we make our next official release, it’ll include an installer. But for these weekly and daily builds, you need to handle some of it on your own, unfortunately.
When I just put the downloaded daily build .exe file in the same directory as wfview.exe (it is indeed c:\program files (x86)\wfview\) , I assume I then double click that downloaded file to run it. When I do that I get this:
I did download one dll that seemed to be missing and out it in that same directory.
Another question – I am wanting to download version 1.55. How do I tell which daily build contains version 1.55?
Most likely you are missing the qcustomplot2.dll file, which is also in the build directory.
Just use the latest file, it is going to have the most up-to-date code.
You can check the version number within the program when it runs using the About button. If you really want to know prior to launching it, the .txt files in the build folder show the compiling process, which include the version number, although it is not easy to spot.