OnInputFifoOverrun event - what should an application do?

[astrasel]

Our application (using the X3-10M v1.02 SDK) sets a handler for OnInputFifoOverrun and occasionally it triggers (if we try to do too much stuff while processing the received blocks) but I'm not sure what we should do in response. For example, should we call board->Reset(), packetStream->Stop(), disable the trigger, or some combination of these.

The basic problem is this: we initialize and start the X3-10M, capturing data at a high data rate. Things process fine (no discontinuities in the data) for a while. Our application does something (like trying to write the data to disk while also processing it) to start falling behind. At this point the OnInputFifoOverrun is called, so our app knows this has happened but we don't otherwise take any action (so we keep receiving blocks from the A/D).

The problem is that there are periodic discontinuities in the data that is received after the A/D overrun is reported. I would expect at least one, but it keeps happening every now and then. Also I noticed that the overrun does not seem to be reported again (if similar conditions exist that created the first overrun).

If we stop and re-start our app, things work fine (so there is something in the initialization that is clearing this problem) but I'd prefer to be able to recover without having to re-start.

[astrasel]

Here is what I did to handle this, when fifo overrun event occurs:

1) set an internal flag so that my 'OnDataAvailable' handler stopped pushing data to an internal queue (throw away new data)
2) Stop A/D reception:
board.Trigger(X3_10M::tInput, false);
packetStream.Stop();
wait for 'OnAfterStreamStop' handler to execute
3) Sleep a bit (sleep for 1 second - without this, occasionally got discontinuities even after re-start)
4) Re-start A/D reception:
reset internal flag to process data recieved by 'OnDataAvailable'
packetStream.Start();
board.Trigger(X3_10M::tInput, true);

This is working well. I would prefer a solution that didn't involve stopping and starting the A/Ds. Perhaps something that would just reset the stream somehow. But maybe this is what it takes.