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

[Martin Dvh]

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.
>
> Thanks,
> Eric
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):
>gr_firdes::compute_ntaps(sampling_freq=11822983.000000,transition_width=2436.100000,window_type=0,beta=6.760000)
>returns ntaps=16017  ==> no audio output at all
>gr_firdes::compute_ntaps(sampling_freq=11822983.000000,transition_width=2436.200000,window_type=0,beta=6.760000)
>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:
gr_firdes::compute_ntaps(sampling_freq=11822983.000000,transition_width=2436.100000,window_type=0,beta=6.760000)
returns ntaps=16017  ==> no audio output at all
gr_firdes::compute_ntaps(sampling_freq=11822983.000000,transition_width=2436.200000,window_type=0,beta=6.760000)
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 
output_multiple.
If I use this version of the driver (which still has other problems, it is not 
finished)
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,
Martin