Thanks for this, @jensenpat — nicely scoped and the writeup is excellent. I checked the diff against the code and it's correct on the mechanics:

• bytesForDuration(kWinRxDeviceBufferMs * 1000LL) uses the right units (µs → 50 ms), the if (winRxBufBytes > 0) guard covers the invalid-format 0 return, and setBufferSize() is correctly placed before start() inside the ladder loop (fresh sink per candidate, so it applies on every attempt). ✅
• The default-lowering is consistent across the three places the diff touches (AudioEngine.h, MainWindow.cpp, RadioSetupDialog.cpp), and the effectiveBufMs std::max(...) against the Flex/Kiwi presentation delays means the lower default can't undercut the presentation-buffering floors — good. ✅
• The "mirrors the sidetone/Quindar sinks" claim checks out: CwSidetoneQAudioSink.cpp:97 does set an explicit 50 ms buffer. Worth noting it tops up on a 2 ms timer there, whereas the RX drain timer is 10 ms — so 50 ms gives the RX ring ~5 refills per drain vs. the sidetone's ~25. Still reasonable, and you've correctly flagged that this needs the Windows/USB on-hardware soak before it leaves draft.

Two non-blocking points:

1. Stale comments left behind. The PR updates the default value but not the prose that describes it. After this change these now read wrong:

   • AudioEngine.cpp:1173 — "caps buffer at ~200ms"
   • AudioEngine.cpp:1182-1183 — "Default 200ms, user-adjustable..."
   • AudioEngine.h:738 — "keeps its 200 ms jitter cushion"

   Quick sweep to 100 ms would keep them honest.

2. The Windows device buffer is a fixed 50 ms, not tied to the user-adjustable cap. The app-side cap exists as the escape hatch for high-jitter links (50–1000 ms), but a SmartLink/VPN user who raises it still gets a hardcoded 50 ms WASAPI ring. Network jitter is absorbed by the app-side queue, so that's mostly fine — but the device ring is still exposed to local scheduler stalls, and those users now have no knob to enlarge it. Worth considering scaling it with m_rxBufferCapMs (e.g. min/a fraction) rather than a flat constant, so the escape hatch fully controls device-side latency too. Fine to defer.

Mechanically sound and conservatively guarded — the remaining risk is exactly the underrun question your Windows-validation gate is there to answer. (Minor: no CHANGELOG entry, if the repo expects one for behavioural defaults.)

_{🤖 aethersdr-agent · cost: $6.5985 · model: claude-opus-4-8}

Approving as-is per maintainer request. RX speaker-latency fix for USB/local audio (#3193). Enabling auto-merge (squash) so it lands once the pending build/check-windows finish green.