On Oct 25, 2014, at 5:27, Jeff Long <[email protected]> wrote: > On 10/24/2014 09:02 PM, Kevin Reid wrote: >> What does it mean in the GNU Radio issue tracker for an issue to have the >> status "Feedback"? > > Usually "Feedback" does mean "waiting for user feedback". But in this case, I > think it means "hmm, have to think about that". Both reports have the same > underlying cause. The second one, to do with the resampler, was exposed when > some timing code was fixed.
I had understood the response to #667 (though it was unclear, hence my request for clarification) as that two internal connections to the input port of a hier block should be considered independent -- capable of having passed different numbers of samples depending on how much work the downstream blocks have done -- at the moment the graph is locked and modified. (Which makes sense, though is IMO poor usability, now that I've had it pointed out.) Thus, not the same bug at all. (As it happens, I believe there is an actual bug that I failed to correctly reproduce for reporting -- the original program I reduced phase-bug.py from did not have two separate connections to the hier block port. I haven't commented on this before because there's been no particular use to it until I have a corrected test case.) > In the mean time, setting up a couple of multiply_const blocks and changing > the constant at runtime will work as a switch, even though it's not as > efficient. In my application, the modification to the flow graph may be entirely unrelated to the subgraph affected by the bug, and may be due to the user requesting different processing (hence, creating new subgraphs), so it's not really possible to stick to non-reconfiguring changes. Also, disabling unneeded processing is an important feature, because it makes the difference between reasonable CPU use and an uncomfortably toasty laptop. > Or, putting a stop()/wait()/start() around the call to _do_connect() in both > phase-bug.py and try_die.py makes things work correctly, but might not be > what you want. That might be a useful workaround; I'll keep it in mind. Thanks for the information and suggestions. -- Kevin Reid <http://switchb.org/kpreid/> _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
