Run fftw_execute() once on an empty buffer (Fix #1366), add option to save wisdom and specify plan (#863)

[ai6aj]

Runs fftw_execute() once on an empty buffer to make sure the plan is generated before streaming begins. Fixes #1366 and should fix #1260.

Implements #863, with some changes:

1. Adds a -W option to specify a wisdom file. If the necessary wisdom does not exist (either because the file does not exist, or an equivalent or better plan does not exist in the file) we attempt to save it at program exit.

2. Adds a -P option to specify the planner flags (estimate, measure, patient, exhaustive).

3. There is no reason to use the WISDOM_ONLY flag; FFTW will automatically use the best plan it can find in the wisdom file that meets or exceeds the requested plan type. If one cannot be found, it will be generated and the associated wisdom will be saved for future use (see point 1) if the -W option is specified.

4. FFTW already has a notion of a default system-wide wisdom file. If the -W option is not specified we attempt to load it; if it does not exist we don't complain. We do not attempt to update the system-wide wisdom file.

Some notes:

• specifying wisdom file on the Raspberry Pi greatly reduces the startup time on subsequent runs. Without a wisdom file, a 10K bin size with the default "measure" plan on a RPI4 takes about 30 seconds to start executing. With a wisdom file the startup time is negligible

• FFTW's "import system wide wisdom file" seems to always fail on the RPI (and possibly other systems as well), and the 'canonical' wisdom file generated by fftwf-wisdom doesn't seem to have any hints that help anyway. If a user wants a system-wide wisdom file that works with hackrf_sweep, it's recommended that they generate one using the -W option to hackrf_sweep and then copy it somewhere that all user accounts can access it and chmod it/set the ACL appropriately. Determining the right way to do this on every possible OS that hackrf can be used with opens up a big can of worms that seems like it's way beyond the scope of this tool.

[ai6aj]

No idea what the firmware failures are all about as I haven't touched that code at all

[martinling]

This looks great! I've asked the folks from #1260 to test if it fixes the failure on the Pi Zero 2 W.

The build failures aren't your fault. It looks like the latest arm-none-eabi-gcc package in Homebrew is failing to build libopencm3 due to a missing header. It's happening on the master branch too.

[mossmann]

Thank you so much for the contribution!