-----BEGIN PGP SIGNED MESSAGE-----
I’ve asked a similar question before, so please try and bear with me :).
Is there a way to calculate the delay of all blocks after yours in a
chain? It might be as easy as summing up the histories of all of the
As an illustration of why we need this, consider that the filter blocks
often set_history equal to the number of taps. This means that as soon
as a single sample gets sent through, they can begin emitting data.
However, the data that they emit isn’t useful – not until the filter
block is full of samples. If we’re streaming, this is fine, a minor
However, packet-based applications send a message and then switch back
to RX mode. The upshot of this is that the ends of packets will get
stuck in the filters and not get pushed out until the next data packet
comes through. This (not end-of-packet-ISI) is why we have to append at
least one nonsense byte to the end of a packet in order to make the CRCs
match, and why that end-of-packet error is deterministic rather than
A fix seems to be to appending a number of additional samples (maybe
zero samples) equal to the total pipeline delay to a message in a
message_source. Do we have the facility to do this? Other suggestions?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----