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.
· Change the latency to 200ms for both TX and RX.”
With those settings, it doesn’t work at all. I never get any audio sent to WSJT-X on transmit, even when I try the workaround.
I put it back the way I had it:
Sample rate: 48000
Format: LPCM 1ch 16 bit
And left the latency set to 200ms for both TX and RX.
Then it works initially, but then the audio starts to fluctuate and/or drops out as usual. The workaround will only restore things for a few minutes then it goes back to being flaky.
Think I will buy the Icom RS-BA1 software and be done with it.
This is almost certainly a network issue and changing software is not likely to help!
It is worth checking the log at the point you start to experience audio dropouts, I am betting that there are retransmissions occurring?
How are you connecting to the IC705? If using the internal AP mode, this is known to be VERY flaky. I use a good quality wireless access point (Cambium) and have no problems at any format/sample rate over many hours.
@kh6idf – let us know if the use of RSBA1 makes your life better.
I have with my mesh network here a lot of TX audio problems on the 705 as wireless client when using RSBA1. If I use wfview it gets better though (linux) . Now. if I shut down all the access points except one, all goes fine with both TX as well as RX. RSBA1 drops a bit more but it’s not a big issue.
It’s a well known issue that 705’s forte is not the wireless performance. It drops easy the ball if you are 10m from the AP.