If I run the fft execution on 2 threads, or more, is there any “race”
problem between these 2 threads and the work one? Inj another words,
is it possible that this work being called before finishing the fft
execution?

If it is so, there will be a race problem because “work” wants to
write on d_fft->get_inbuf() while fft execution wants to read from it!

please help me with this code. I don’t know why at the runtime, the
data I give at the output aren’t desired after a while!!

is there any “race” problem between these 2 threads and the work one?
I think you might be confused what the FFT multithreading means here; I
hope I can illustrate this. Let’s set the FFT multithreading level to
two threads:

The work thread waits for fft->execute to return; there can be no
interference while the fft threads run, because at that time, the work
thread isn’t “active”.

Inj another words, is it possible that this work being called before
finishing the fft execution?

no, a single block’s work() cannot get called before the previous run of
work() has finished. That wouldn’t make any sense – how would the
second work now how many input samples it has, if the first one hadn’t
already consumed?

Your code looks correct. I know I tell you this in almost every
discussion on here, but:
Please, tell us what “undesired” means. That would greatly reduce the
guesswork for the rest of the mailing list.

Also, sliding FFTs do look like a computational heavy load. What is the
application for that? I ask because getting an fft_length FFT for every
item increases item/sample rate without giving you
(information-theoretically speaking) any advantage over doing one FFT
ever fft_length samples.

Also, sliding FFTs do look like a computational heavy load. What is
the application for that? I ask because getting an fft_length FFT for
every item increases item/sample rate without giving you
(information-theoretically speaking) any advantage over doing one FFT
ever fft_length samples.

Sliding FFTs are used to provide spectral estimates with higher temporal
resolution, while sacrificing (to some extent) the overall quality of
the estimate.

Hello Marcus,
I checked my sliding fft works fine and the bug was somewhere else

In fact I want to detect a known sequence within data non-coherently.
After
detection I want to neglect this ‘work’ process.
How would you prefer to stop this work process after detection?
(Something
like putting this thread to sleep! )

spawn thread 1 & spawn thread 2
interference while the fft threads run, because at that time, the work
Your code looks correct. I know I tell you this in almost every discussion
Greetings,
/*

Sliding fft is fundamentally different from spectral estimation in
practice. Because in practice we never do sliding on sample by sample to
get estimate of spectrum.

The using purpose of sliding fft here is something else.

Best,

On Sat, Oct 25, 2014 at 6:08 PM, Marcus D. Leech [email protected]
wrote:

Sliding FFTs are used to provide spectral estimates with higher temporal