The input blocks to the valve, when open, connect to null sinks. The idea was to drain any incoming data. This could be desirable if for example you had other blocks, like a file sink that also used this stream. You wouln't want to back-up indefinitely and then consume all the old data when closed again. It depends on the topology. So maybe the user should decide...
I think the valve needs a user-set policy. Consume when open, or block when open. And while we are at it, for the outputs, produce zeros when open, or block when open. -Josh On 01/07/2011 04:13 PM, Patrick Strasser wrote: > Hello! > > I'm trying to implement an application with GNU Radio Companion that > incorporates different branches. For example I have a Wav source and a > signal source and I want to switch between them. Or I want to hear the > signal at socertain points in the flow graph. The old way was to use a > variable chooser, const multipliers for muting of paths and adders. The > downside of this system is that all the paths continue to run > concurrently. I do not use the muted paths, but they still consume > processing power. > > Now I found the valve block, and the doc says: Connect output to input > when valve is closed (not open). > I expected the valve to block when input is not connected to output. I > thougth the flow graph would starve/block on that path. In consequence > the path would not consume processing power. Now it seems - referring to > Josh's message from 2010-05-06 [1] - that down the path from the valve > indeed starving happens, but the null sink in the valve happily > consumes, keeping the producers running. > > I thought about replacing the null sink with something blocking. This > would for sure work with otherwise unconnected sources, like when > choosing between different sources. But I'm not sure what happens if the > path splits before the valve. Would the blocking be propagated back over > the split or be limited to the path with the valve? > > Maybe I'm just on the wrong track and there is some other simple > solution for this problem. > > Regards > > Patrick > > [1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
