[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] several changes to CVS
From: |
Prateek Dayal |
Subject: |
Re: [Discuss-gnuradio] several changes to CVS |
Date: |
Tue, 18 Jan 2005 04:03:02 -0800 |
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