On Fri, Oct 12, 2012 at 5:57 PM, Alex Zhang <cingular.a...@gmail.com> wrote: > Hi Tom, > > There is the other thing I need to confirm: > It looks that the block's output buffer size can not be changed after its > construction, right?
On the latest git master/next, you can change the buffer size once before you run the flowgraph. The buffers are actually created when you call top_block.start(), and we've put in a call to the gr_blocks that allows you to set the maximum buffer size. But you cannot change it afterwards, even when you lock/unlock (you'd have to delete the old block and create a new one). The allocation of gr_buffer space is a very costly operation. You really, really don't want to be adjusting this during runtime. Tom > On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <t...@trondeau.com> wrote: >> >> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <cingular.a...@gmail.com> >> wrote: >> > Let me take an example for my question. >> > >> > For some OFDM blocks, the io signature is determined by the fft length, >> > during the constructing the block. However, sometimes, we need to adjust >> > the >> > the fft length dynamically based on some physical environment or >> > computing >> > environment. >> >> Hi Alex, >> >> I haven't thought about this too much, so my recollection of how >> things work could be a bit off. But I'm pretty sure that the answer is >> no, you cannot dynamically adjust this. You'd be messing too much with >> the scheduler. >> >> The way that you can do it is to lock the flowgraph, swap out the >> block in question with a new block that has the new parameters, and >> unlock to restart the graph. But you are going to lose samples in the >> buffers into the block that you're removing. >> >> This would actually be a great case for the event stream scheduler. >> You could have different processing graphs that are selected based on >> the state that you need. So you could populate graphs of different FFT >> lengths and then dynamically select the right graph based on an event >> when you detect a different length is required. This is still a >> work-in-progress: https://github.com/osh/gr-eventstream. >> >> Tom >> >> >> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <cingular.a...@gmail.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> I know it may not be possible in the current gnuradio blocks framework, >> >> but I am still curious if it can be done. >> >> When I write a signal processing block, the io signature could be >> >> determined by some parameters. It is ok, if these parameters are fixed. >> >> But >> >> sometimes, especially in the adaptive system, I need to dynamically >> >> update >> >> these parameter, which result in the updating of io signature of the >> >> blocks. >> >> I can make the io_signature to be independent with the dynamic >> >> parameters, >> >> but it could be more convenient if the io signature can be adapted. Of >> >> course, it is not easy, as the io signature change could impact the >> >> upstream >> >> and downstream. >> >> >> >> Thanks, >> >> >> >> -- >> >> >> >> Alex, >> >> Dreams can come true – just believe. >> >> >> > >> > >> > >> > -- >> > >> > Alex, >> > Dreams can come true – just believe. >> > >> > >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > > > -- > > Alex, > Dreams can come true – just believe. > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio