Michael,
Thanks for the response! Apologies for the unclear question. Here's another shot:
Can one call to the work function yield multiple offsets from the `get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)` call? With multiple offsets then that means there are multiple sets of PDUs (assuming that the stream was created from pdu_to_tagged_stream). Let's say for fun that there are 3 PDUs like the following (CAR, CDR):
- ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
- ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
- ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
What I'm curious about is whether or not a single call to work() will end up with tags for more than one of the PDUs above. For instance, if the buffer for the block is large enough, would 20 samples get lumped in to a single call to work() resulting in say offset 0 and offset 10 both showing up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)'? This of course assumes that pdu_to_tagged_stream and tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.
I seem to remember having that very issue once. I got multiple offset values in a work() function in the past. Pretty sure I did at least O.o Really, just curious if there is a guarantee somewhere deeper in the block code that ensures that can't happen.
As I write this I realize that this is a pretty easy thing to test out. If it's still unclear, then I'll just do that and post results :)
Thanks!