Multi thread fft execution

Hi all,
I have the following c++ code which gets fft by sliding on sample by
sample
fo the input.

/*

 * The private constructor

 */

sliding_fft_impl::sliding_fft_impl(uint fft_size)

  : gr::sync_block("sliding_fft",

          gr::io_signature::make(1, 1, sizeof(gr_complex)),

          gr::io_signature::make(1, 1, fft_size * 

sizeof(gr_complex))),

    d_fft_size(fft_size)

{

    d_fft = new fft::fft_complex (d_fft_size, 1, 2);

    set_history(fft_size);

}


sliding_fft_impl::~sliding_fft_impl()

{

    delete d_fft;

}


int

sliding_fft_impl::work(int noutput_items,

    gr_vector_const_void_star &input_items,

    gr_vector_void_star &output_items)

{

    const gr_complex *in = (const gr_complex *) input_items[0];

    gr_complex *out = (gr_complex *) output_items[0];


    memcpy(d_fft->get_inbuf(), in, d_fft_size * sizeof(gr_complex));

    d_fft->execute();

    memcpy(out, d_fft->get_outbuf(), d_fft_size * 

sizeof(gr_complex));

    //delete d_fft;

    return 1;

}

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!!

Best,

Mostafa

Hi Mostafa,

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:

sliding_fft_impl::work()
            |
  enter "fft->execute"

spawn thread 1 & spawn thread 2
| |
calculate calculate
| |
±-------v-------+
join threads
|
return from “fft->execute”
continue ::work

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.

Greetings,
Marcus

On 10/25/2014 08:26 AM, Marcus M. wrote:

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 :slight_smile:

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! )

Best,
Mostafa

On Sat, Oct 25, 2014 at 3:56 PM, Marcus M. [email protected]
wrote:

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,
/*

}

    gr_complex *out = (gr_complex *) output_items[0];

Mostafa
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/


That would be a case for flow graph reconfiguration, most probably :slight_smile:

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


Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/