Hey all — some really impressive work happening on client-side DSP. @EI6JGB has been building out a spectral noise reduction (NR2) implementation using the Ephraim-Malah MMSE-LSA algorithm with OSMS noise floor tracking. This is serious DSP engineering — proper overlap-add processing, decision-directed smoothing, speech presence probability, anti-musical-noise temporal gain smoothing, and a clean FFTW3/radix-2 fallback architecture. Genuinely excellent work.

This opens up an exciting direction for AetherSDR — client-side DSP that complements what the FLEX FPGA provides. The radio's built-in NR is great for most situations, but stacking a different algorithm on the demodulated audio can help pull out weak signals that the radio's NR alone can't clean up. And since we're processing at 24kHz mono (not RF rates), the CPU cost is minimal — roughly 1-2% of a single core.

One thing I wanted to get community input on: FFTW wisdom generation on first launch.

The current implementation uses FFTW_PATIENT planning for FFT sizes up to 262144, which can take several minutes with a modal progress dialog. A few ideas to make this seamless:

1. Background generation with immediate fallback — NR2 starts instantly using the built-in radix-2 FFT. Meanwhile, FFTW wisdom generates in a background thread. When it's ready, we hot-swap to FFTW3 on the next audio frame. No modal dialog, no waiting.

2. Only plan what we need — NR2 uses 256-point FFTs at 24kHz. Planning just the 256/512 sizes takes seconds, not minutes.

3. Ship pre-computed wisdom — Include a wisdom file for common FFT sizes in the repo.

4. Use FFTW_MEASURE instead of FFTW_PATIENT — ~10x faster planning with negligible quality difference at 256-point FFTs.

My preference is option 1 + 2 combined: instant NR2 via fallback, lazy background FFTW planning for only the sizes we use.

Thoughts? Anyone else working on client-side DSP features?

73 de KK7GWY