popping and crackling smartSDR 4.1.5 on any remote connection not hardwired?

Nice summary.

What you are running into is not a defect in the radio or SmartSDR, but the realities of real-time communications over IP networks, especially over Wi-Fi and cellular.

Streaming HD video and real-time SDR audio are fundamentally different problems.

Video streaming works well because it is buffered. If packets arrive late, the player simply waits a few milliseconds and hides the problem. SmartSDR cannot buffer RX audio the same way without destroying real-time operation and operator timing. When packets arrive late, out of order, or are dropped, you hear them immediately as pops or crackles.

However, Wi-Fi, consumer routers, and cellular links are optimized for throughput, not latency or jitter. They aggressively queue, reorder, and delay packets — all of which are poison for real-time SDR audio. A green SmartSDR network indicator means acceptable, not ideal, conditions.

For reliable remote RX audio, especially SSB, the network must be tuned for low latency and low jitter, not raw bandwidth. This typically includes. This is why Network gurus make the big bucks and go to school for a long time.

• Ensuring no bufferbloat (a very common issue on consumer routers)
• Preferencing UDP traffic and avoiding “smart” packet inspection features
• Using strong, uncongested Wi-Fi (or avoiding Wi-Fi entirely when possible)
• Avoiding mesh hops, extenders, or powerline adapters
• Testing cellular links — many simply are not suitable for continuous real-time audio

The ASUS RT-AC68 series, while popular, is known to introduce buffering and latency under certain conditions unless tuned carefully.

Features like DAX, remote audio PCs, or third-party solutions exist not because SmartSDR is poorly designed, but because there is no universal consumer network that guarantees real-time behavior. These tools allow users to adapt to the limits of their specific network environments.

• Yes, out of the box is good enough for local operation and many remote setups.
• No, out of the box cannot overcome poorly behaved or latency-heavy networks.
• This is a limitation of IP networks, not FlexRadio.

We absolutely understand the frustration — remote operation is one of the strongest reasons to own a Flex. The next productive step is focusing on network latency and jitter, not bandwidth, and tuning the router and Wi-Fi path accordingly. Once that is addressed, the popping you describe typically disappears entirely.

If you turn the FPS and RATE way down, does the problem go away totally?

Make sure you turn off any Green Power settings.

In the Router, try turning off anything that does not prioritize UDP packets as we want to reduce any lantency/jitter.

Others may have some good insights with this router.

And, don't forget that the NIC card in the Client end is a key part of the transport path. You'll want to make sure that the drivers are up to date on it.

73

Good point. Integrated graphics and their drivers can introduce DPC latency and memory bus contention, which can disrupt real-time RX audio. This isn’t about raw CPU speed, but timing jitter in the system. Discrete GPUs and platforms with better driver behavior often avoid this, which may explain why some laptops struggle while iPads or desktops work well.

If you are getting a 1 second delay, you need to dig deeper. I use both an Eero and Deco Mesh in 2 different locations without issue.

I use both of them in a bridge mode if that helps.

I see what you mean. :) No, that won't happen to be honest. We spent about a year to get it down to what it is now, which is amazing.

I would spend some time in ChatGPT asking it very detailed questions. You can even draw a picture with radio, model numbers, etc and paste the image in. Your priority is UDP packet streaming through your communications layer. I think you'll find it an education. The more details you provide the more accurate it gets.