[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] get_tags_in_range
From: |
Nowlan, Sean |
Subject: |
Re: [Discuss-gnuradio] get_tags_in_range |
Date: |
Mon, 10 Mar 2014 15:16:58 +0000 |
>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