RPi4 and Trunk Recorder Startup Errors - Boost

[blantonl]

When running Trunk Recorder on a brand new RPi4 I'm getting the following errors on startup. Any ideas?

gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc0) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc1) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc2) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc3) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc4) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc5) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc6) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc7) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc8) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc9) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc20) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc21) max output buffer set to 3072 instead of requested 4096
gr::log :WARN: flat_flowgraph - Block (fft_filter_ccc22) max output buffer set to 3072 instead of requested 4096
Allocating 15 zero-copy buffers
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >'
what(): boost::thread_resource_error: Resource temporarily unavailable
Aborted

 

[blantonl]

I'm finding this only occurs with an Airspy... disabling the airspy in the config seems to resolve the problem.

I've tried building the latest OsmoSDR from source and recompiling trunk-recorder but that doesn't seem to fix the issue. Not sure what's causing the problem.

 

[boatbod]

Those errors are coming from the gnuradio library rather than the osmocom driver. Not sure why they would be Airspy specific; perhaps due to the bandwidth of the device? Try temporarily reducing the sample size to see if they go away.
~/gnuradio-3.7.11/gnuradio-runtime/lib/flat_flowgraph.cc line 114 (assuming you have the sources to gnuradio pulled from the repo)

 

[blantonl]

Could be - it's an Airspy mini running at 6M - might be exceeding a resource limitation, even though the RPi4 has a USB3 controller. Thanks for the pointers....

 

[nick0909]

Did you figure out anything about this warning, or just ignore it? I'm seeing the same (not on a pi).

 

[blantonl]

No luck here... I haven't gotten an Airspy to work with the RPI4 yet.

 

[nick0909]

I'm not on a pi 4, just a regular PC running Ubuntu 18.04 server, but get the same warning except it seems to work so far... I guess I'll ignore it...

 

[boatbod]

My airspy works on an RPi4 with op25, so whatever is broke seems specific to TrunkRecorder rather than the airspy driver.

 

[blantonl]

So good news here. I've gotten this working by:

1) Upgrading to the latest boost libraries with a standard apt dist-upgrade
2) Compiling the latest version of trunk-recorder 3.1.2

I still get the warnings but it's working perfectly now.

 

[lukekb]

On those warning - I tried to turn the buffer size down to make sure there is not a lot of audio queued up in the GnuRadio graph. I am not sure if it does any good though, so I might look at removing it. Either way, those warnings shouldn't impact anything.

 

[jwestyp]

I have the airspy working with trunk recorder. The only issue remaining is the ability to decode TDMA: true. If a talkgroup is TDMA true, then it won't decode. Everything else is decoding properly and sounds good.

 

[mtindor]

No luck here... I haven't gotten an Airspy to work with the RPI4 yet.

My Airspy R0s and R2s have worked fine with PI3/PI4 (aside from the ridiculous CPU usage that makes them really unusable on an RPI platform). My Airspy mini (6 msps) doesn't work, just like yours. Complains just the same. Interestingly, just like an Airspy is 10 msps but really can only pick up perhaps 8-9 msps because the outer edges have no gain, I think the Airspy mini can only be counted on to cover around 4.8 msps out of 6. I only say this because if you attach an Airspy mini to spyserver, the highest option for sample rate is 4.8 msps. No option for 6 msps. So I'm wondering if the mini must have the freqs you are trying to cover within a 4.8 msps spread.

I'm disappointed. I have a few RPI3bs, RPI4s, and an Odroid N2. The Airspy R0/2 kill them all with the CPU usage. I really was hoping to replace some of the Airspys with Airspy minis.

Mike