Re: [Discuss-gnuradio] Re: handling bursty data

[Eric Blossom]

On Mon, May 16, 2005 at 09:34:00PM +0000, Volodymyr Kindratenko wrote:
> Rahul Dhar <rdhar <at> cmu.edu> writes:
> 
> > 
> > this?  I'm thinking of buffering along the Tx path, specifically.  Will
> > data that is buffered in the host stay there until the next time the
> > sink block is run, or does everything written to the USRP Tx eventually
> > make it to the Tx d'card, even if the Tx sink block is never run again?
> > I'm seeing behaviour that could either be that not all data is
> > transmitted, or maybe my synchronization sequence isn't long enough.
> > Either way, it seems that there needs to be a "critical mass" of data
> > being transmitted continuously before recovery works (based on the
> > fsk_rx/tx example: it doesn't work sending a file in non-looping mode,
> > at least for me)
> 
> We have a different setup, but the same problem as you.  Our data source is a 
> file descriptor source made from a socket.  But since the source uses 
> blocking 
> read, the entire data processing pipeline becomes blocked when there is no 
> data to read.  Our solution was to re-write parts of the file descriptor 
> source to check if there is data in the socket, and, if there is, read it, 
> but 
> otherwise inject 0s.  This way the data processing pipe always has something 
> to process.  Of course you need some sort of an application-dependent higher-
> level intelligence to drop those 0s on the receiving side.

As a variation on a theme, you could pass an additional "status"
stream through the pipeline in parallel that indicated whether there
was really data or not.

I'm open to suggestions as to how you guys who have these kinds of
challenges want the system to behave.  At a minimum it shouldn't be
hard to for example turn off the Tx if there's no data available for
it.  Then blocking on the read side should work as expected.

Eric