Hi Martin, this won't 100% answer your Q's, but perhaps it'll help:
On Thu, Feb 14, 2013 at 02:37:43PM +0100, "Martin Lülf" wrote: > Dear list, > > I have another question regarding stopping the flowgraph. This time it is > about streaming blocks, no messages involved at all. > > My flowgraph looks like this (block A) --byte--> (block B) --byte--> ... > > Block A is a byte source that signals EOF at a certain point, lets assume > after sending out 11 bytes. > > Block B is a ratio 1:1 sync block which works on groups of input items, > say 5 bytes. If B's work is provided with less than 5 samples it will > return 0 and wait to get more samples. We do this a lot in the experimental OFDM branch; an easy example might be the CRC block: https://github.com/benreynwar/gnuradio/blob/ofdm/gr-digital/lib/digital_crc32_bb.cc > Unfortunatley the blocksize of block B is not fixed but based on a state, > so I can't call set_output_multiple to tell the scheduler to only provide > me with multiples of 5 bytes because a few items later it might change to > 6 bytes. You *can* call set_output_multiple() from within work(). Remember to re-set it. > As you can see from the example above B will process the first 10 bytes > like expected, but then there is still one byte left to be processed by B. > The problem I have is to detect whether block B is asked to process only > one byte, because that's all the scheduler has so far (but A will produce > more), or if it is asked to process this one sample because that is the > last one available (A has already signaled EOF). > > Is there any build in way to detect that the previous block in the > flowgraph has already signaled EOF? The only way I could think of is to > attach an EOF stream tag to the stream in the previous block A and > evaluate the tags in block B. Are there any other approaches/ideas? Might > a general EOF tag be a good idea for gnuradio (so that file source and > head or even the scheduler itself attach the EOF tag)? My guess is stream tags are the easiest solution. If you're saving state anyway in your downstream block, you might as well add another case for the final block, i.e. a tag that says "here's 3 items, and there won't be any more". In most cases, a dedicated EOF tag wouldn't be useful, though. When a file source hits EOF, it usually shuts down the flow graph by returning -1, and the downstream blocks eventually stop, too. This might even be enough in your case; if you use set_output_multiple() in work, there is still something (but not enough) in the input buffer for your block B, and you don't really need to process that (because it's just a dangling byte), perhaps this is all you need. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
pgpE3w16iTnCt.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
