Re: [Discuss-gnuradio] set_relative_rate

[Miklos Maroti]

Hi Tom,

Thanks for the answer! I have considered both approach already. What
you are saying is that set_relative_rate cannot capture this scenario,
so it is impossible to set different relative rates, right?

Where exactly are the relative rates used in gnuradio core? Only for
the buffer size calculations or are they also used during runtime?

By the way, the vector approach does not scale ideally: if I increase
the size of vectors (to 100000 samples) or use set_output_multiple
with that large value then the performance of the block is degraded,
and I do not really understand why. If the block does pure streaming
(e.g. add) and does not require large quantities of data, then
everything works fine. I do not want to use messages, because the data
is processed (filtered, length changed, etc) along with other
transformations. Anyhow, what I am getting at that there is no good
way of processing very large blocks of data.

Miklos

On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau <address@hidden> wrote:
> On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti <address@hidden> wrote:
>> Hi Guys,
>>
>> Is it possible to write a c++ block that takes 2 input streams,
>> produces 1 output streams, but to generate 1000 outputs it needs 1000
>> inputs of the first kind and 1 input of the second kind? How do I set
>> the set_output_rate? Does it apply to both input streams? How can I
>> ensure that the scheduler does not create too big buffer for the
>> second type of input?
>>
>> Miklos
>
>
> There are a couple of ways to do this. It might be easiest for you to
> use vectors of samples on input port 0. The output could be another
> vector or you could convert it to a stream again here. This is
> assuming that you always want to process 1000 samples at a time for
> every 1 sample on input port 1. You set your IO signature like:
>
> gr::io_signature::make2(2, 2, 1000*sizeof(type0), 1*sizeof(type1))
>
> The output signature is either 1000*sizeof(type0) and you can use a
> gr::sync_block (because 1 output item is 1 input item) or your output
> signature is 1*sizeof(type0) but you'll use a gr::sync_interpolator
> because now you'll be producing 1000 items after taking in a stream of
> 1 item. See vector_to_stream for a model of this second approach.
>
> You might also want to consider the tag stream interface instead of an
> indicator on stream 1. You would then have one input stream but look
> for the tag to process your 1000 output samples. This would be a more
> general approach if you aren't always using 1000 items at a time.
>
> Tom