Re: [Discuss-gnuradio] get_tags_in_range

[Nowlan, Sean]

>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.
>
Ok, I guess I should go poke around the prune_tags logic and see how it works. 
If it respects history(), it wouldn't prune tags from any item that is 
available at the start of the read pointer, including history. If it doesn't, 
tags may be abandoned/pruned even though I have access to history()-1 number of 
previous items, and I'm still stuck.

Functionally speaking, if I can read a sample, I should be able to read its 
associated tags. But history() only involves input buffers, not output buffers, 
so perhaps I'm still falling into the trap mentioned above, i.e., the tag may 
be pruned before the downstream block can see it.

>But something like this, if not exactly, should work, yes.
>
I'm trying to determine an "exact" solution. This is another way to work around 
PFB arb resampler tag propagation issues (discussed in issue #652). Basically 
I'm adding a start-of-burst tag to the first sample of a stream pre-resampler, 
and then once things have been resampled, I go back and fill in end-of-burst 
tags. This avoids having to know when the PFB arb resampler adds +/- 1 samples. 
This block I've written is a sync_block that simply does a memcpy of samples 
and the tag processing mentioned above.

Now I'm thinking a workaround could be to return noutput_items-1 items. This 
way I get to check the last item of a work input buffer, 
nitems_read(0)+noutput_items-1, for a start-of-burst tag and place an 
end-of-burst tag at nitems_read(0)+noutput_items-2. At the next call to work, 
that last item of the previous input buffer is the first item of the input 
buffer, and I can put an end-of-burst tag at nitems_read(0) if I find a tag at 
nitems_read(0)+1. Makes sense in my head, at least...

>Tom

Sean