I don’t think that recv_async_msg() blocks. So an infinite loop will chews up CPU.
The production o O/L/D/U happens independently. I’m struggling with multi laptop failure right now or I’d get you more info on shutting those off. I assume that redirection is not appropriate because your application uses stdout? Sent from my iPhone > On Jan 3, 2022, at 5:14 PM, [email protected] wrote: > > > Hi Marcus, > > I’ve attempted to use uhd::tx_streamer::recv_async_msg() before, but it > slowed down my application and caused frequent lates on the tx_streamer. I’m > unclear on the intended usage. I tried creating a separate thread that polls > in an infinite while loop looking for async messages. Am I inadvertently > adding contention over a mutex hidden somewhere inside tx_streamer? If I > handle the async message, does that prevent UHD from printing “L” to stdout? > > > > This only handles part of my issue. What about the Rx side? For my > application, I am not issuing individual Rx stream commands, only a single > one on startup to constantly receive. I then call uhd::rx_streamer::recv() in > an infinite loop. I check the error code returned in the form of a > uhd::rx_metadata_t. How do I prevent it from printing “D” to stdout in the > event where I drop a packet? > > > > As a side note, why should I upgrade? Normally I would just try to stay up to > date with libraries I’m using, but for this particular application I have a > bunch of air gapped systems that are difficult to release new libs onto for > largely bureaucratic reasons. I haven’t noticed any new features in the > release notes I need, and my application has good enough performance, so I > never bothered updating UHD. > > Thanks, > > Richard > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
