Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

>1. The gnuradio-runtime propagated tags with double arithmetic; the >fractional resampler block used mixed float & double arithmetic to >propagate tags. > Oops: mixed float & double arithmetic to generate output sample intervals. -Andy ___

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote: > Hi Eugene > > > From: Eugene Grayver > > Date: Thu, 9 Nov 2017 19:52:35 + > > > > There is a major problem with the way tags are propagated in blocks > > with non-integer relative rate. If the ratio is not a power of two, > >

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

(and if I'd actually read Andy's last post carefully ...) On 01/01/2018 01:32 PM, Jeff Long wrote: As Eugene suggests, the fractional resampler can be handled by doing a linear mapping from the input to the output of a single work call. Wouldn't this work with most or all blocks? There would

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

As Eugene suggests, the fractional resampler can be handled by doing a linear mapping from the input to the output of a single work call. Wouldn't this work with most or all blocks? There would also need to be an offset in order to handle history. Then, there wouldn't be a need to use higher

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

I think the reason rate changes are difficult for tags is that the block executor tries to guess what a block is doing based on its long-term or static rate change. The block itself knows exactly how input items relate to output items, and maybe certain blocks need to provide more feedback

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Hi Marcus: On Sun, 2017-12-31 at 15:09 +, Müller, Marcus (CEL) wrote: > Hi Andy, hi Eugene > > Hm, coming back to an idea I had not so long ago: > > tag offset should not be 64bit unsihned integers only, but also have > a > 64 bit fractional part. > > That would not immediately solve the

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Hi Eugene: On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote: > Hi Eugene > > > From: Eugene Grayver > > Date: Thu, 9 Nov 2017 19:52:35 + > > > > There is a major problem with the way tags are propagated in blocks > > with non-integer relative rate. If the ratio is not a power

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

I suppose if you don't have 64 bit, you can just shift it to be 32-bit and sacrifice the lost precision. There's probably other possibilities, but I think the newer ARM stuff is going 64-bit anyhow. On Mon, Nov 13, 2017 at 2:01 PM Marcus Müller wrote: > Ok, see your point. I

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Ok, see your point. I was a bit hesitant at first because that will end up needing 64bit division (which might really not be much fun on many ARMs), but meh, it's not like someone should be pushing tags around as if they're samples. Cheers, Marcus On Sun, 2017-11-12 at 23:33 +, Dan CaJacob

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Why not make the sub-second offset a uint64. That way you can express time to the atto second (I think). The precision is overkill, but uint32, which barely breaks a picosecond is underkill. On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller wrote: > Hi Eugene, > > yup,

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Hi Eugene, yup, fully agree, the whole concept is slightly broken. So, first of all, I really think the key problem we're constantly working around is that tags have an integer offset – which leads to rounding errors, even in relatively benign scenarios. I'd propose we add a fractional part: