That would be a case for flow graph reconfiguration, most probably :) On 26.10.2014 06:13, Mostafa Alizadeh wrote: > 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! ) > > Best, > Mostafa > > On Sat, Oct 25, 2014 at 3:56 PM, Marcus Müller <[email protected]> wrote: > >> 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 >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> 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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
