raspberry pi 4 server + mac client = robotic tx

I had this issue back in 1.2 and kind of gave up, and recently setup 1.5 from source on pi, and installed 1.5 in mack book pro. I have attempted all sorts of audio changes, systems, devices. RX is pretty good, but TX i only get 1 tx in before all subsequent TXs are robotic sounding. the only way to fix is restart client wfview but the problem easily reproduces itself.

any hints what could be wrong?

Hi Dave,

A couple of questions:

  1. What radio?
  2. What audio system is selected on the server?
  3. What audio system is selected on the Mac?
  4. What codec is selected on the Mac?
  5. What is the audio device on the Mac used for the microphone?
  6. What kind of network connection is being used?

I think if you answer these for me then we can at least figure out what to look at.


de W6EL

Hello all

I have simillar issues and I have a different setup:
ICOM 7100 connected to quite beefy DELL Laptop with i7 / 16G RAM / SSD
running Windows 11/64.
All drivers are installed. I have two options.
As I have fixed IP on laptop (or static lease) I have port FWD on WAN Router(OpenWRT) and I can use either public IP or VPN (Wireguard). In both instances I connect to an radio and all is good unit I start to transmit. Audio is initially OKish, but lately becomes robotic. It seems like the jitter buffer is getting full up and emptying but it is happening on both TX Buffer being 500ms or set at lowest possible or middle (250) etc. Reconnecting wfview client helps to solve that for a while.

On the stats i see occasional packet loss (3-5 per minute) but eventually I got 3000mS RX Buffer and RTT of 35mS.

Would be good if we could tune the buffer to perhaps use larger buffer or to empty itself after a while a start from scratch… just an ideas.

Jiri OK2IT

Hi Jiri,

What audio system is selected at both ends (client, server)?

Also, I recommend that you set the sample rate to 16K and the codec to “Opus 1ch”. This will greatly reduce the required bandwidth. Set the latency sliders to the middle.

The beefy Dell sounds sufficient for the server. What’s the client computer like?

It is known that sometimes there are issues with VPNs mangling UDP packets, but I believe with the Opus codec it is less of an issue (Phil, correct me if I’m wrong here). Check the log (press the Log button) to see if you’re getting a lot of “retransmit” or “missing” packet issues, it can indicate issues with the wifi.

Your setup should be working better, let’s see if we can figure it out.

de W6EL

Hi Elliot !
Thanks for reply. First of all I might want to update progress and perhaps be more specific about the setup:

  1. The DELL Laptop is beefy but its connected to wifi (I have a LAN USB Adapter on order) altough it sits on same room as enterprise AP from Extreme Networks and I have setup voice/video QoS for VLAN with wfview.

  2. My internet connection is also done over 802.11n technology since its remote location and ISP doesnt use Canopy or simillar but resorted to Ubiquity / Microtiks. Measuring showed that I have a 30mbps down and about 8mbps uplink. I also used HPSDR / Hermes Lite SDR but since ISP changed something last week ago I have a big UDP packetloss. I therefore ordered a cable VDSL connection.

  3. Client is also DELL Laptop connected directly to FTTH Modem and I have about 300mbps available with 3:1 split.

I was playing with various settings and it seems that best results I get are with:
SERVER - Qt Audio
CLIENT - RT Audio 16000bps sampling rate and Opus 1ch eah way.

My log for shure shows:

022-11-27 03:14:02.774 INF udp: udpAudio : Missing SEQ has been received! “0x40c3”
2022-11-27 03:14:02.774 INF udp: udpCivData : Missing SEQ has been received! “0x257c”
2022-11-27 03:14:03.263 INF udp: udpAudio 1 or more missing packets detected, previous: “0x40da” current: “0x40dc”
2022-11-27 03:14:03.360 INF udp: udpAudio : sending request for missing packet : “0x40db”
2022-11-27 03:14:03.456 INF udp: udpAudio : Missing SEQ has been received! “0x40db”
2022-11-27 03:14:46.038 INF udp: udpAudio 1 or more missing packets detected, previous: “0x4936” current: “0x4938”
2022-11-27 03:14:46.039 INF udp: udpAudio : Missing SEQ has been received! “0x4937”
2022-11-27 03:15:16.133 INF rig: Unknown meter level (0x15) received at register 4294967176 with level 250
2022-11-27 03:15:23.971 INF udp: udpCivData 1 or more missing packets detected, previous: “0x319a” current: “0x319d”
2022-11-27 03:15:23.974 INF udp: udpCivData : Missing SEQ has been received! “0x319c”
2022-11-27 03:15:24.032 INF udp: udpCivData : sending request for missing packet : “0x319b”
2022-11-27 03:15:24.067 INF udp: udpCivData : Missing SEQ has been received! “0x319b”

so I am pretty sure it is network related. Question is is there a way I can use less samples / 8000bps or is there a way to reset a voice stream (TX) and drop the queue or is there a timeout on the udp voice queue? What seem to happen is when I talk and there is a sequence mismatch, the voice gets garbled and slowed down a lot , like if I would take the voice stream and put a wait 1mS between each frame. I will try to make a recording of it and attach it :slight_smile:

wfview-20221125213454.log (1.6 MB)
wfview-20221127030803.log (21.1 KB)


Here is the LOG from the SERVER Side. Also here I see udp adui udp CIV streams not well.

I cant attach ZIP or WAV I have recorded. I might need to creat a folder and share this way.


I have made a shared folder where I put WAV recording from a WEB SDR. I will put more files in eventually and I will either make a list.txt or I will rename the files so they make sense.

It does not matter what soundsystem I am using – so it must be 99.9% network related. I used to run skype with a FT450+cat and plain simple data interface which seemed to run…well…ok-ish, sound wasn’t good and audio tx wasn’t great either, but I had a good rx and tx overall. Is skype audio using somehow different method to correct for the missing udp frames? I am seeing Opus CODEC along with wfview to sometimes ask for the UDP missing packet to be rentransmitted (sort of like TCP) but if it takes way too long, it gets deleted from the queue.

I will keep you posted, but I am positive that once ISP is sorted, all will be well. Maybe we can finetune this for other who also got unfortunate situation of having a radio on the HILLTOP or quiet location where internet isn’t at its best😊

73 and Thanks all team for such an Amazing piece of SW!!!

PS – I kniow ICOMM sells theit RS-BS1…still… are there any major differences now???