Is DAX v2 less tolerant of network jitter?

glevar

Recently the audio quality of the DAX audio connection between my 8600 and my remote operating location has gotten much worse. I have Comcast at home and the radio sits on a starlink connection. For about a year I was able to run clean DAX audio to my home with this network. Now it is unusable with continuous chopping and cut outs.

I have run wireshark/tcpdump at various points in the network path and I am seeing bursty packet delivery of the audio stream. Lots of packets with over 10ms gaps and repeated gaps of 20 to 60 ms between packets.

I see the Dax packets showing up like clockwork every 5.3 ms on the local LAN by the radio. I also see them departing the router on the way to the starlink unit with correct 5.3 ms timing.

I am currently running a priority starlink plan so I have a public IP. The network quality at the remote location according to SmartSDR is excellent and packet loss is basically zero.

I also recently moved to 4.2.20 so that means upgrading to DAX v2. Is DAX v2 more sensitive to network performance than DAX v1?

Before I go crazy trying to figure out what may have changed in some carrier network, is DAX v2 less tolerant of packet timing variations? I never went through the network at this deep per packet level before because I set it up and it worked, so these timing variations may have been there all along but maybe the old DAX protocol was able to deal with it so I never noticed?

Any ideas are welcome.

Thanks!

George NQ9N

Mike-VA3MW

My guess is that Starlink has more Jitter than other ISPs due to the additional delays due to using LEO satellites. I searched online for similar and found gamers reporting the same issue.

DAX (all versions) send all their audio data via UDP packets. With any congestion, network switches, by design, will drop UDP packets to deal with congestion. UDP datagrams are using in streaming solutions because each packet is sent and the sender doesn't know and doesn't care if the information got to the end user. They are fire and forget missiles.

UDP datagrams are more efficient and require less overhead than TCP datagrams. We use TCP when every bit of data has to arrive and be correct.

Normally, we would not know or care especially in video, podcasts or even VoIP applications. For audio, you might hear a click from time to time. These are the missing datagrams.

In my early days of HF remote operation, 2006, I had the same problem especially trying to run digital programs and only have 1 mB of upload from the radio.

I quickly decided to run a PC at the remote site. That turned out to be the right move as I run all my logging, digital and other Ham Radio programs on it. For Digital programs, this is a must have since I no issue running FT8 with a remote desktop connection. Even today, with my MAC and trying to run Remote FT8 with the receiver audio being sent over the NET the copy is not as good due to lost datagrams.

I explain more in this video as to why this is a good idea (and, not that hard to do).

Oh, one more thought as I write this, and, maybe this is your issue. Are you using WiFi at all? WiFi can be evil in real time VoIP applications (which, this really is). Can you test on a hardwired connection?

I hope that helps a bit. Others might have ideas as well.

73

https://youtu.be/zJNGa6sKq6s?si=Zq2XHDng5AkwoM3l

glevar

Thank you Mike.

I have seen the instability that wifi can cause and I am running all wired connections.

I did packet captures at the radio LAN and at my remote computer simultaneously and then matched up the packets streams. I see each packet making it through the path. The only difference in the two captures is the distribution of inter-packet timings.

Since it all worked great for about a year with basically perfect audio across the WAN path then suddenly so much chop as to be unusable something had to change. The question is whether it’s anything I can do something about or is something buried inside a carrier network.

If I have to go with running digital modes via remote desktop to the computer next to the radio I can do that, it was just nice to not need that extra layer.

George NQ9N

KD0RC

Hi George, I just helped to set up a club station here. We have a 6400 in a nice rural location. People were trying to operate FT8 with DAX traffic coming in via the WAN. It kind of worked sometimes, but mostly had too many dropped packets. Receive was generally ok, but during transmit, it lost data like crazy. It looked like RF was getting into the network gear, but it was actually just data overload causing the dropped packets.

To fix it, we put a NUC at the radio location. WSJT-X, DAX and CAT all run on that NUC and are controlled via Remote Desktop. The operator runs SmartSDR using SmartLink.

The extra layer is well worth the effort to keep that two-way UDP traffic off the WAN.