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 12:03 PM, Mostafa Alizadeh wrote:
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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
