Get_tags_in_range

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.

Sean

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

On Mon, Mar 10, 2014 at 5:55 AM, Martin B. [email protected]
wrote:

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

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

On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean
[email protected] wrote:

absolute sample offsets and tag bookkeeping.
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

independent of the data stream except that offsets are used for

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs