-----BEGIN PGP SIGNED MESSAGE-----
yes, that is expected behaviour. Most probably
For explanation: Since GNU Radio itself always passes around multiple
items at once (so your work doesn’t get called), all throttle can do is
limit the average rate, unless it would consume one input item at a
time, stall work as long as necessary and then output that one item.
For higher sample rates (where the flow graph is nearly CPU-limited),
which is the original use case of throttle (stopping GNU Radio from
completely clogging the CPU) this would imply a considerable overhead.
What you can try is call the public
gr::block::set_max_noutput_items(int) method on your throttle block
prior to starting the flow graph. This should tell the scheduler to
call the throttle’s work function with smaller numbers of input
samples (also, it reduces the output buffer size if that is feasible
for the downstream block).
Also, try smaller values for the max_output_buffer size of the vector
source, maybe (that could be even accessible in the GNU Radio
companion block property dialog).
one more question in that context: why the vector to stream? the
vector source can output single samples, too. Just set the vector
length to 1.
On 16.03.2014 17:35, Volker S. wrote:
mailing list [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----