Summary

This change fixes a long-standing FT8 receive timing problem on macOS DAX where WSJT-X and JTDX could show a consistent positive DT offset even when the radio connection itself had very low network latency.

The fix adds live-edge protection to the macOS DAX RX shared-memory ring so stale audio cannot build up and get delivered to digital-mode clients as if it were current audio. It also keeps lightweight timing counters in the bridge for support and verification, while gating the periodic summary diagnostics behind the existing DAX logging category so normal production logs stay quiet.

Problem

Users reported that FT8 decodes over local Ethernet and Wi-Fi were consistently late by roughly +1.5 s to +1.6 s in both JTDX and WSJT-X. The symptom was severe enough to cause missed QSOs even on otherwise healthy local networks.

A few characteristics made the issue especially suspicious:

• the problem reproduced in both JTDX and WSJT-X
• ICMP and normal network timing looked healthy, often in the 1 ms to 12 ms range
• the DT values were commonly shifted in the same positive direction across many stations
• the offset was large enough to look like buffered or stale audio rather than transport latency

That pattern strongly suggested a local audio-queueing problem instead of RF propagation, remote-station clock drift, or ordinary LAN/Wi-Fi latency.

Root Cause

On macOS, DAX RX audio is written into a POSIX shared-memory ring in VirtualAudioBridge. That ring is intentionally large enough to hold about two seconds of 24 kHz stereo float samples so the CoreAudio/HAL side can read from it asynchronously.

The bug was that the macOS RX path had no live-edge protection at all. If the consumer side fell behind even briefly, the ring could accumulate a large backlog and continue serving old samples from the past rather than current audio from the radio.

That created a fixed positive FT8 DT bias because the decoder was not hearing the current symbol boundary. It was hearing delayed audio from the shared-memory queue.

This also explains why network diagnostics did not match the observed FT8 delay:

• ping measured network transport latency
• the FT8 DT error was caused after packets had already arrived, inside the local DAX RX buffering path

The existing TX path already had stale-backlog protection. The RX path did not. That asymmetry was the key indicator.

What Changed

1. Add RX live-edge backlog clamp on macOS

When DAX RX backlog exceeds a bounded threshold, the bridge now advances the reader to keep only a small recent slice of audio near the writer head.

Current thresholds:

• target backlog: about 40 ms
• clamp threshold: about 200 ms

This prevents digital-mode clients from decoding stale audio if the shared-memory reader falls behind.

2. Add lightweight RX timing counters

The bridge now tracks per-channel RX timing state:

• written sample time
• trimmed sample time
• trim event count
• overrun event count
• peak backlog within the reporting window

These counters are intentionally small and local to the macOS DAX bridge.

3. Keep diagnostics available without making production logs noisy

Two forms of diagnostics are available:

• clamp events when the bridge has to jump back to the live edge
• once-per-second summary timing lines

The summary logs are gated behind the existing aether.dax debug category, and clamp messages are only emitted when DAX info logging is enabled. That keeps the production default quiet while preserving support visibility when troubleshooting is needed.

Why This Is Safe

This change is scoped to the macOS DAX implementation only.

• VirtualAudioBridge.cpp is compiled on Apple builds
• Linux continues to use PipeWireAudioBridge.cpp
• Windows does not use this macOS shared-memory DAX bridge path

The fix does not change demodulation, sample-rate negotiation, rig control, or radio transport. It only prevents stale RX audio from remaining queued in the macOS DAX bridge long enough to skew FT8 timing.

Investigation Notes

During investigation we also checked the application side to make sure the delay was not coming from a hidden client-specific RX ring.

• WSJT-X showed normal Qt audio buffering behavior with no built-in multi-second queue that explained the symptom
• JTDX uses a similar QAudioInput-based RX path and did not reveal a client-side RX ring matching the observed DT shift

That helped narrow the failure path back to Aether's DAX RX bridge.

We also added timing summaries temporarily and observed the following before the logging cleanup:

• RX backlog could briefly grow into the hundreds of milliseconds
• when clamped, backlog was pulled back toward the live edge immediately
• after the fix, the large common positive DT bias disappeared

Validation

Build validation

• cmake -S . -B build -G Ninja
• cmake --build build --parallel 10

On-air validation

• reproduced the original symptom before the fix with positive FT8 DT bias across both JTDX and WSJT-X
• observed the backlog clamp and per-second DAX timing summaries during troubleshooting
• reduced the shared positive DT bias from roughly +1.5 s / +1.6 s down into the normal few-tenths-of-a-second range
• ran for about four hours with stable DT and no observed drift
• completed a clean FT8 QSO at 0.0 delta time with no message retries using the final build

That final on-air behavior strongly supports that the stale-audio backlog was the actual root cause.

Files Changed

• src/core/VirtualAudioBridge.cpp
• src/core/VirtualAudioBridge.h

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.4 Pro) and tested by @jensenpat