[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] dummy block has huge impact on usability fir filt

From: Martin Dvh
Subject: Re: [Discuss-gnuradio] dummy block has huge impact on usability fir filter
Date: Mon, 17 Jan 2005 07:32:19 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041124)

Eric Blossom wrote:
On Mon, Jan 17, 2005 at 01:32:48AM +0100, Martin Dvh wrote:

Can you please update gnuradio-core (gnuradio-core/src/lib/runtime/gr_single_threaded_scheduler.cc is the
file that matters) and try your test with and without the dummy block?

I am compiling the new version right now. I will let you now the results as soon as possible.

After some more thought, I believe that what I previously checked in
ISN'T going to fix the first part of the problem.

I've checked in a different fix.  If you've still got some time,
please update and try again.  This backs out the change to
gr_single_threaded_scheduler.cc and adds a change to flow_graph.py

In the case with no dummy block, I think that what we're seeing is a
deadlock between your source and the high decimation rate fir.  The
latest change increases the buffer allocated to your source to a
minimum of 2 * output_multiple.


A first test show the following:

>using extra dummy block:
>        adj_in = gr.add_const_ss(0)   #dummy block which does nothing
>        fg.connect ( src0, adj_in )
>        fg.connect ( adj_in,  chan_filter1 )
>debug output(I added printfs):
>returns ntaps=16017  ==> no audio output at all
>returns ntaps=16015  ==> works
With the your new code and using dummy block there is no change, exactly the 
same behaviour

not using extra dummy block:

I used to get audio only if ntaps was below 317
Now I get:
returns ntaps=16017  ==> no audio output at all
returns ntaps=16015  ==> I do get some audio, intermittend (short bursts of 
audio, probably there now is a bottleneck somewhere else)
I am going to do some more tests tomorrow.
The good news is that I do get some output with higher tap numbers now.
The bad news is that adding the dummy block still gives an improvement.

I also rebuild my driver to try to get it to work without requiring a high 
If I use this version of the driver (which still has other problems, it is not 
I get "normal" output in both cases untill I get a number of taps above 16015, 
After that I also get no audio at all, like with the other driver.

Thanks and greetings,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]