Swap out GR processing blocks on the fly?

Question

I was wondering if it's possible to stop a processing graph, swap one of its blocks with another with the same number of input/output channels and data types, and restart it, without tearing down the entire graph? So for example:

MAX = 10000

class my_top_block(gr.top_block):
  def __init__(self, peak_hold=80):
    gr.top_block.__init__(self)
    self.sample_rate = 10e3
    self.s = gr.noise_source_f (gr.GR_UNIFORM, MAX)
    u = foo.peak_fv (MAX, peak_hold)
    self.connect(s, u)
    self.v = foo.wait_vv ()
    self.connect(u, v)
    self.t = gr.null_sink (4 * 1024)
    self.connect(v, t)

  def set_peak_record(self, record, peak_hold=80):
    self.stop()
    if record == True: 
      u = foo.peak_record_fv (MAX, peak_hold)
    else: 
      u = foo.peak_fv (MAX, peak_hold)
    self.connect(self.s, u) 
    self.connect(u, self.v) 
    self.start()

This is somewhat contrived, but I hope it illustrates my question. Thank you!

Answer 1

It sounds like you need to use the Stream Selector block in gr-basic:

http://lists.gnu.org/archive/html/discuss-gnuradio/2011-11/msg00228.html

In the future, I think you will find the GNURadio mailing list is a better medium for asking for help regarding GNURadio. All of the devs are extremely active on the mailing list, but as far as I'm aware, it's only me and a couple of others that monitor Stack Overflow for GNURadio questions =)

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Cheers,

Ben

Answer 2

Yes, you can arbitrarily rearrange the flow graph and I've written code that does it much like you show. What you specifically have to do in order for changes to take effect is to precede them with self.lock() and follow with self.unlock(). (Note that lock/unlock pairs cannot be nested.) I don't recall offhand whether stopping and starting will have the same effect.

I have met quite a few block-specific quirks, for example:

• hier_block2.disconnect_all breaks the block's inputs and outputs, but individual disconnects work fine. (Now fixed.)
• On Mac OS X, the audio.source and audio.sink stop working after the first restart or unlock. (Being fixed.)
• blocks.throttle's timer runs continuously (so if you take it out for a while and put it back in later, it will run too fast until it catches up).

However, these can all be worked around and they are problems with specific blocks' implementations, not the basic concept of reconfiguring the flow graph. I have yet to encounter any problem which is inherent to reconfiguring in general.

(It may well be the case that the stream_selector mentioned in HokieTux's answer is faster and more reliable for the cases it can handle, but I felt I should report that arbitrary reconfiguration is an option.)