Re: [Discuss-gnuradio] several changes to CVS

[Prateek Dayal]

Dear Eric,

If I have made some blocks on my own, then when I update CVS, I loose
the makefiles in  which I put reference to my blocks and compiled. Is
there a way I can save all the re-editing of makefiles after updating
CVS.

Regards,

Prateek 


On Mon, 17 Jan 2005 18:58:28 -0800, Eric Blossom <address@hidden> wrote:
> Hi folks,
> 
> I've recently checked in several fixes.
> 
> * Absent new evidence, I believe that I have fixed Martin and Chuck's
> problem where the system would consume cpu cycles but not produce any
> output (or produce a small amount and then stall).  It turns out there
> were two problems.
> 
> The first was that too small a buffer was being allocated for Martin's
> high output_multiple A/D source.  This combined with the immediately
> following high decimation rate filter lead to a livelock situation
> where the filter consumed enough input to make a bit of progress, but
> then there wasn't enough room in the buffer for the A/D to write.
> 
> The second was that the scheduler wasn't checking to see if it was
> feasible to fulfill a particular request for input data, and would
> just keep trying (and failing).  With FIR filters with huge number of
> taps (8K - 16K taps), the filter block would say that it needed more
> contiguous data than we had buffer space allocated.  Now the scheduler
> checks for this condition, prints out a diagnostic, and marks the
> block as finished.
> 
> I'm not likely to make changes to support > 8K tap filters.  If you
> need thousands of taps in a decimating filter, you are going to be a
> whole lot better off building a multistage filter.  You split the
> decimation and transition bands across the two stages.  It's possible
> to compute a optimal partitioning between N stages given the total
> decimation factor and the desired transition band.  This is left as an
> exercise for somebody besides me.  [It's not tough, the number of taps
> is basically linear in the normalized width of the transition band.
> You want to minimize cycles consumed by all the sections.]
> 
> * I've modified the audio_alsa_source so that it works around hardware
> that always runs in stereo mode.  This means that it now sounds right
> to use only a single output from the audio source even if the hardware
> only does stereo.  The sink was already correct.
> 
> * There was an unexpectedly large amount of latency when using the
> spectrum_inversion.py example.  Instead of a couple of milliseconds,
> there were 10's of milliseconds of latency.  The problem was tracked
> down to the handling of the "repeat" option in gr.vector_source.
> Moral of the story: if your work method CAN produce noutput_items, it
> really should...
> 
> If you're tracking CVS, now would be a good time to update everything
> and rebuild.  As always, let me know of any problems.
> 
> Eric
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


-- 
Prateek Dayal
B.Tech 4th Year
ECE
IIT Guwahati

www.geocities.com/pmd_iitgw