The hackrf_sweep tool should run the FFT once on an empty buffer at startup, before actually starting the sweep, and discard the result. That would get the planning out of the way before actual data starts flowing, rather than having the first FFT call delay the USB callback whilst FFTW plans and sets up the FFT implementation. On slow hosts with large FFTs, this delay can be enough to cause a timeout.
I expect this will fix #1260.
See also #863, which would allow caching that work between runs. However, in the initial case where there is no cached plan, we would still need this change to avoid a timeout.
What type of issue is this?
permanent - occurring repeatedly
What issue are you facing?
The
hackrf_sweeptool should run the FFT once on an empty buffer at startup, before actually starting the sweep, and discard the result. That would get the planning out of the way before actual data starts flowing, rather than having the first FFT call delay the USB callback whilst FFTW plans and sets up the FFT implementation. On slow hosts with large FFTs, this delay can be enough to cause a timeout.I expect this will fix #1260.
See also #863, which would allow caching that work between runs. However, in the initial case where there is no cached plan, we would still need this change to avoid a timeout.
What are the steps to reproduce this?
See #1260.
Can you provide any logs? (output, errors, etc.)
No response