Workaround to no audio on startup on Win 10 for IC-705

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.

https://termbin.com/8h7e

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:

https://termbin.com/4gq43

Confirmed this morning it’s fine in 1.2 playing on FT8.

Matthias and Ronald,

can you tell if you have a meshed network? E.g. multiple access points that eventually talk to each other?

I have been connecting my laptop to the 705’s built-in access point, not through my home Wi-Fi.

Thanks,

Ron

thanks for that information. And how far are you away from the rig, is it next to you or…

I have normal double glass windows, if the rig is outside and I’m inside, at approxmax 5m, I’m close to the edge of having it to work at all.

The radio is on the desk next to me and the laptop - less than a meter of air between all.

Latest follow-up on my experience…

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.
  • Disconnect, select Speaker (Realtek), reconnect - audio output works.
  • Disconnect, select VB Audio Cable, reconnect - audio output works.
  • Disconnect, select Realtek Speaker, save settings, exit wfview
  • Launch wfview - audio works
  • Disconnect, select VB Audio Cable, reconnect - audio output works.

PortAudio (continue in same session above)

  • Disconnect, select PortAudio as Audio System.

  • Many items in Audio Output pull-down list

    • Microsoft Sound Mapper is first
    • Cable Input (VB Audio Virtual Cable) is fourth
  • Select Microsoft Sound Mapper, save settings, exit wfview. (Log 1)

  • Launch wfview, windows closes shortly after opening. (Log 2)

  • Launch wfview again, no connection at first, connects 23 seconds later, then window closes. (Log 3)

  • Launch again, windows closes shortly after opening. (Log 4)

  • Launch again, cancel connection, select VB Audio Virtual Cable as Audio Output, save settings, exit wvfiew. (Log 5)

  • Launch wfview, audio output works.

  • Disconnect, select Microsoft Sound Mapper, reconnect - audio output works.

RTAudio (continue in same session above)

  • Disconnect, select RTAudio as Audio System.
  • Speaker (Realtek) is the only item in pull-down list.
  • Save settings, exit wfview. (Log 6)
  • Launch wfview, no audio output.
  • Disconnect, try to select Speaker (Realtek) from pull-down list (despite it being the only entry).
  • Reconnect, no audio output, exit wfview. (Log 7)

(After this I went back to my PortAudio config that works without issue at startup.)

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 :thinking:, 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”. :smile:

73 VR2XHQ

1 Like

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.

Cheers,

Ron

KM4OO

1 Like

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.

Hi kh6idf,

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.

–E
de W6EL

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?

Thanks

Hi kh6idf,

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.

For example -DWFVIEW_VERSION=\"1.55\".

–E
de W6EL

That was it, it runs now. I’ll see if it fixes the audio problem (I hear it does).

Thanks

The transmit audio is still flaky with version 1.55. After a few minutes it starts to fluctuate / drop out.

Check your log for network issues (missing or re-transmitted packets).

Also, disconnect and:

  • Change the sample rate to 16k
  • Change the format to uLaw 8-bit
  • Change the latency to 200ms for both TX and RX.

(and then connect again)

That’s my advice for more reliable audio.

–E
de W6EL

“Also, disconnect and:

· Change the sample rate to 16k

· Change the format to uLaw 8-bit

· 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.

Wondering if you rebooted after making those setting and then tested? I find that I need to reboot after changing some settings like audio settings.

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.

73 Phil M0VSE

@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.

ps be sure to get RSBA1 v2 !

I’m using “Station (Connect to Network)” to connect the 705 to my home wifi network.

I seem to have a stable configuration now, I have been running WSPR on 17M for over an hour and it’s still working. My settings are:

RX/TX latency both 200
RX/TX codec both LPCM 1ch 16 bit
Sample rate 16000
Audio System QtAudio

I do have some packet loss, 498/275371
rx latency is 171 ms, rtt is fluctuating but is usually 10ms or less.

1 Like