[Discuss-gnuradio] several changes to CVS

[Eric Blossom]

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