|Subject:||Re: [Discuss-gnuradio] Notion of buffering up input data in GNURadio|
|Date:||Mon, 25 May 2015 20:48:58 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0|
On 05/25/2015 09:03 AM, address@hidden wrote:
So, you're writing that application and ask us how your buffering works? that doesn't sound right, so maybe I'm misunderstanding you?
I think you should really read the guided tutorials I've linked to in my last email; you're trying to replicated functionality that is central to GNU Radio.
GNU Radio cares for your block's in- and output buffers. Unless your work explicitly consumes input items (e.g. by returning a positive number), GNU Radio accumulates the samples in your input buffer.
Don't you care, GNU Radio does that for you!
When your work() is called, GNU Radio knows how many items you can consume (from the input) and how many you can produce (on the output) -- your job as a developer is just writing an algorithm that can work on an array of samples that lies sequentially in memory.
If you know how much items you need at once (e.g. you always need 127) you can use set_output_multiple (which will inherently set the input multiple on a sync block, i.e. any block with a work(), not a general_work()), and GNU Radio will only call you if there's at least 127 items of input.
Whilst your block is working on its input, new input might already occur from the block upstream -- that's no problem at all (in fact, it's what's pretty awesome about the current GNU Radio scheduler). Right after your current work() call is finished (i.e. has "return"ed), work() will be called again, with whatever you left untouched of the input from last time plus the new items.
|[Prev in Thread]||Current Thread||[Next in Thread]|