Hi Philip, Check out line 188: https://github.com/osmocom/gr-osmosdr/blob/master/lib/osmosdr/osmosdr_src_c.cc
It would appear that other driver writers have followed the lead of Ettus and use the same letters to indicate the same error. I've only looked at this code for an entire five minutes, but it looks like the code is initialized with a string that is fed to a dictionary, and after that, _buf_len's size is set from the dictionary, or if there's no entry in the dictionary, sets it to 15. Perhaps you could increase your buffer size? Also, if you're building from source, perhaps you can use -O2 or -O3 when you build it? I don't see any optimization flags set in the top-level CMakeLists.txt In my limited experience with overflows, the two solutions I have used are 1) sample the input at a lower rate, or if the input sample rate has to be at whatever level it is, 2) decimate the samples as soon as possible. Regards, Sean On Tue, Aug 8, 2017 at 8:53 PM, Philip Hahn <hah...@gmail.com> wrote: > Hi Sean, > > I am not using UHD blocks, I am using osmocom source/sinks. I did not see > any warnings about changing buffer sizes. > > Thank you, > > philip > > On Tue, Aug 8, 2017 at 8:42 PM, Sean Horton <seanhorto...@gmail.com> > wrote: > >> Unless I'm mistaken, only the usrp sink/source blocks report overflow >> (source) or underflow (sink). You can see this mentioned in >> uhd/docs/general.dox (uhd github repo). >> >> Did you listen to the warnings you get on startup about changing buffer >> sizes with a series of commands requiring sudo? That helped me resolve some >> overflow, otherwise it sounds like you'll need to drop your sample rate >> unless you need it as high as it currently is. >> >> Regards, >> Sean >> >> On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn <hah...@gmail.com> wrote: >> >>> Folks, >>> >>> Is there a way to diagnose which block first reports an overflow in a >>> flowgraph? >>> >>> In my particular instance I am running a flowgraph which is overflowing >>> without pegging either RAM or CPU. >>> >>> Thank you, >>> >>> philip >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Sean Horton >> >> > -- Sean Horton
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
