HiJeon - It is quite possible that some presentations contain minor
typos or even errors. Research/development and presentation of it is
imperfect at best. Discussion such as this is the right thing to do! If
anyone catchesminor typos or errors in any GRCon15 presentation (or,
for that matter, a paper relevant to SDR / GR / GRCon), please ping this
list and the researcher/developer/presenter so that the info is
searchable and might even be fixed in some future paper/presentation.
All of the above said, hopefully Tom is reading through these emails &
can respond…Thanks for getting the discussion started! - MLD
Here’s a long-winded answer. You’re correct, but I wanted to make sure
the terminology was clear.
Tag offsets in add_item_tag() are absolute, relative to the beginning of
the sample stream, not relative to input or output buffers. But it’s
probably safer to think in terms of absolute number of items written to
each output buffer. For rate-changing blocks, the input/output offsets
will be different. In add_item_tag(), you specify an output port, so
that’s another reason to think in terms of output samples.
Yes, get_items_in_*() fetch tags from a stream on an input port. Again,
offsets are absolute, so input buffers are not really relevant. But, it
makes sense to search for tags related to the samples in the input
buffer. The easiest function to use is get_tags_in_window(), which
simply adds nitems_read[port] to the provided offsets. The absolute
offset is available as a field in each tag. The get_tags_in_range()
function does the same thing, just without adding nitems_read[port].
You could search for tags whose offsets are earlier/later than the
offsets of the samples in an input buffer. However, older tags are
likely to have been deleted, and future tags (I think this can actually
happen) would be really confusing.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.