Re: [Discuss-gnuradio] get_tags_in_range

[Tom Rondeau]

On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean
<address@hidden> wrote:
>>On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun <address@hidden> wrote:
>>> On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
>>>> I'm using get_tags_in_range with bounds outside the absolute sample
>>>> offsets presented in each work function. I'm using this to add
>>>> end-of-burst tags at offset K-1 for every start-of-burst tag that I
>>>> find at offset K (except the very first K).
>>>>
>>>> I just want to confirm that this is valid. All my tests have shown
>>>> that it is, since I believe the underlying deque is completely
>>>> independent of the data stream except that offsets are used for both
>>>> absolute sample offsets and tag bookkeeping.
>>>
>>> I think you're right, but only if you do this *after* the current
>>> bounds, not before.
>>>
>>> M
>
>>Yes, the scheduler prunes all tags before the window after work is done. 
>>Basically, since we're tagging a data sample, if that sample is no longer 
>>available to you, neither is it's >tag. You'll have to get them and store 
>>them locally for your uses later.
>
>>Tom
>
> Ok, that makes sense; I'd be unable to read tags from the past. But what 
> happens if I *create* a tag on a past data sample? Will it be propagated or 
> ignored?
>
> (   A  )  {     B       }
> (0   1)  { 2   3   4 }  5 ...
>
> Let's say section ( A ) is from a previous call to work. Let's also say { B } 
> is the current work window, i.e., nitems_read(0) == 2 and noutput_items == 3. 
> If I find a start-of-burst tag on absolute offset 2, is it impossible to 
> create a new tag on absolute offset 1?
>
> The vast majority of the time, this would not be a problem. The boundary 
> condition is really the only source of trouble. I suppose I could  use 
> set_history(2) so that I can always see the tags at the offset range 
> endpoints. Do you advise this? Does history ensure the scheduler doesn't 
> prune tags from the history region?
>
> Sean


Yeah, if you set a tag to a time in the past, the following blocks
will (likely, based on the dynamics of the scheduler) prune it before
your follow-on block can process it.

I'd have to double check and think about the case where you use
set_history for this. It seems like it should work, but just remember
that set history really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the
stream since index 0 of the buffer /is/ item-2 already.

But something like this, if not exactly, should work, yes.

Tom