Audio click

Hello,

I have annoying audio clicks present while using vfview 2.11 together with IC705 over WiFi.

My initial thought it is packet loss issues (and probably it is), but I do not observe loss counter increase during those clicks. I also find out that these clicks correlate with log events:

2025-05-26 17:58:24.194 DBG udp: udpAudio 1 or more missing packets detected, previous: “0x4eb8” current: “0x4eba”
2025-05-26 17:58:24.208 DBG udp: udpHandler 1 or more missing packets detected, previous: “0x39c5” current: “0x39c7”
2025-05-26 17:58:24.261 INF udp: udpAudio : sending request for missing packet : “0x4eb9”
2025-05-26 17:58:24.262 INF udp: udpHandler : sending request for missing packet : “0x39c6”
2025-05-26 17:58:24.275 DBG udp: udpAudio : Missing SEQ has been received! “0x4eb9”
2025-05-26 17:58:24.277 DBG udp: udpHandler : Missing SEQ has been received! “0x39c6”

It says missing packets were recovered, but then why clicks are heard ?

Any ideas what goes wrong here and can it be fixed ?

It can be a lot of things, audio is tricky.

What operating system are you using?

First disconnect and try a different audio system. We offer Qt, Port, and RT. Sometimes a different library will make all the difference. Make sure the right audio device is selected after changing audio systems.

You can also try knocking your sample rate down to 16k or even 8k. This drops the data rate significantly and might help with occasional network glitches.

—E
de W6EL

Using Windows 10.

I have already tried changes You suggested and there are pros and cons with each config.
Since v1 using Qt Audio and LPCM16 as best choice.

What I’m assuming there could be a “bug” either in vfview or in Qt Audio. Reason why I think so is because if packet is recovered there should be no click audible.

You don’t mention if you changed the sample rate? 16 KHz will result in 25% of the packets of 48 KHz and is almost indistinguishable.

No this isn’t a bug, each packet is 20ms of audio, if one is missed and retransmitted, it will often take longer than 20ms for this to happen, so it isn’t possible to re-assemble the missing packet in time.

The WiFi implementation in the IC-705 is pretty poor and requires a very strong and stable WiFi connection. I usually use commercial WiFi access points like Aruba, Cisco or Cambium and they work well. Some user grade devices are not as stable and will result in retransmissions.

I did tried to change to LPCM 8 bit and used manual pooling set to 100ms. Also changed some setting on my WiFi AP. Those changes helped to avoid some network problems, but not eliminated clicks problem. I will try to change sample rate too.

I think ability to reassemble is related to buffer size. Buffer in my case was ~300ms. Timestamps in log say 2 lost SEQ were received in 83ms. To me it looks like it was enough time to recover successfully.

Maybe another log entry about success or failure of re-assemble could be useful.

That is NOT the sample rate, there is a separate combobox to set that, try 16 KHz like @eliggett and I have already said.

The key is not to have lost packets in the first place as that indicates a problem with your network.

I understand Your point on eliminating network problems, I try my best, but it is not possible to do so for 100%. I have ~15 WiFi networks in range all the time :).

If 16 KHz is not sample rate, then which combo box ?

No it is sample rate, I meant what you had changed so far wasn’t!