On 11/02/2011 08:03 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 16:43, Marcus D.
Leech <address@hidden>
wrote:
To be clear, the problem appears to be with the block itself.
GRC correctly adds the "set_delay" callback spooge.
But calling that callback in the C++ code doesn't appear to
affect the delay.
Changing the delay via the callback changes the history
requirements of the block, which will not take effect until the
thread executing the work() function returns, and could be
hundreds or thousands of items in the future. But it does take
effect eventually.
One way to change this behavior would be to implement the pattern
used in the FIR blocks for when the number of taps changes.
Changing the delay would set a flag that the work function could
check for and return immediately. However, this wold come a high
price, as the work() function currently uses memcpy to move data
from the input to the output, and instead you'd have to have an
iterative loop with a conditional equality check in the middle.
Johnathan
Your assertion that "it does take effect eventually" appears to not
be true in reality (at least in this little test graph) (attached).
Looking at the code, there's an inline function, set_delay, that
calls set_history(). And the SWIG goop appears to be correct.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
|
delay_test.grc
delay_test.py