Also a very good solution, but requires that you always get exactly 1024 items, not
sometimes 1024, and in some cases 100, or 1023.
On 28.06.22 19:13, WarMonkey wrote:
I think "processing more samples" should be prohibited because the length of each buffer
is limited.
Use "set_output_multiple()" function to keep noutput_items equal to N*output_multiple (N
is a positive integer).
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3
<https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3>
Perkins, Daniel (US) <perki...@battelle.org <mailto:perki...@battelle.org>> 于2022年6月29
日周三 00:47写道：
I have written a source block that reads an IQ data stream from a socket.
____
It is my understanding that:____
* the work function should attempt to process the number of samples as
determined by
the noutput_items variable____
* processing fewer samples is acceptable____
* processing more samples is not recommended____
__ __
My socket packets contain a fixed number of samples so to avoid an extra
memory
transfer, I prefer to copy straight from the socket buffer directly to the
output
buffer with a volk function. To make this work, I need to return that
number (1024)
of samples from the work function which sometimes violates the “processing
more
samples” rule. However, this seems to work without any issues and only the
occasional
dropped UDP frame. I can also manipulate what GNU Radio will assign to
noutput_items
by calling set_min_noutput_items. When I set the min nouput_items to the
size of my
payload, I get a bunch of underruns. What is the optimal way to deal with
this?____
