Hi Fabien, risking sounding a bit cliché: Well, you need to fix your bug. The underflow should not be happening!
An easy solution, if this is just a manner of occasionally insufficient, but on-the-medium-term more-than-sufficient processing speed, a larger buffer between the USRP source and the next block, maybe? Maybe we can otherwise help you improve the performance of your application :) Just let us know! Best regards, Marcus On 30.10.21 00:20, Fabien PELLET wrote: > Hi, > > Thanks for the answer. > > At the moment, it seems that catching the underflow message and then > lock/unlock the > flowgraph permits to reset the buffers and is enough for my application to > get reasonnable > and not growing forever latencies. I don't if someone know a better way like > a C++ method > that could do that more "elegantly". > > If I need more predictible latencies in the futur, indeed, I will try to use > tags as you > suggest. > > Regards, > > Fabien, F4CTZ. > > Le 27/10/2021 à 17:02, Sylvain Munaut a écrit : >> Hi, >> >> >>> OK I understand that. But is there any solution which permits to reset that >>> growing >>> propagation delay ? How to reset the flowgraph buffers without killing the >>> application >>> and restart it ? Is there any method that permits to purge and resync >>> buffers of the >>> flowgraph ? >> The USRP supports timestamps for RX and TX. >> So you get tags for when data was received / is supposed to be transmitted. >> Using a custom block to modify the RX tags into TX tags ( to change >> the RX timestamps to TX timestamps a bit into the future ), you should >> be able to achieve a constant controlled latency. >> >> Cheers, >> >> Sylvain >
smime.p7s
Description: S/MIME Cryptographic Signature