Hi Daniel
On 28.06.22 18:44, Perkins, Daniel (US) wrote:
* processing more samples is not recommended
Not only not recommended, it's strictly forbidden, and breaks GNU Radio.
You get only as much output buffer as you get noutput_items. You produce more, you're
overwriting parts of previous calls' output.
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.
Then your block is broken! This probably only works because you don't notice how you're
overwriting data that has not yet been processed.
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.
That's the right thing to do.
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?
What happens here is that GNU Radio waits to call your work function until the processing
downstream has consumed enough items so that there's 1024 or more items of space in the
output ring buffer.
If that takes longer, on average, than it takes your source to produce these samples, you
have a problem: You're trying to attach a hamster to a water hose and tell it to drink
fast enough. No matter how big you make that hamster's cheek pouches, at some point the
hamster will have to spill some (overflow), if it can't drink as fast as the hose pumps in.
So, the solution is to both set min_noutput_items, and to make sure the rest of the
flowgraph is fast enough so that there's always enough space for your work() to write into.
Best regards,
Marcus
PS: I swear, no hamsters were harmed in the making of this email!
