Improve CPU efficiency

[corpr8]

Currently, the audio glitches using Shinysdr (buffer under-runs) when streamed aross my network (from Beaglebone to Laptop), however - when I use a command line similar to the following:

rtl_fm -M -l 10 -f 118.82M | sox -t raw -r24k -es -b16 -c1 -V1 - -t mp3 - | socat -u - TCP-LISTEN:18080

The audio streams fine. Would be great if Shinysdr could do similar (in terms of squeezing the audio server side).

Having a look around github, I noticed a Python module for transocding audio:

https://github.com/devsnd/python-audiotranscode

[kpreid]

The BeagleBone Black simply doesn't have enough CPU power to run ShinySDR in its current state. I know this because I tried just that configuration myself. The audio underrun is because everything is underrunning.

There are multiple factors here:

• ShinySDR is built on GNU Radio, which is a modular framework and therefore has overhead, whereas rtl_fm is hardcoded to do the one particular job.
• ShinySDR is doing more things simultaneously — not just audio, but the spectrum display and all the other meters and things. (Some of this can be optimized.)
• And, of course, ShinySDR is doing some things inefficiently.

It's close enough that I would like to make it work at some point. Here are some things you can already do for a little bit of improvement:

• Run the volk_profile command-line tool, if you haven't already. This will run some tests and write a config file telling GNU Radio how to run its DSP operations most efficiently.
• Reduce the configured sample rate for the RTL device (1,000,000 MHz is the minimum recommended value). This will narrow the spectrum view but make the filter for the demodulator more efficient.
• Use the mono-audio mode: config.set_stereo(false).
• Turn the FFT rate control down to its minimum (1).

Here are some fixes beyond “general optimization” that I have in mind for the future.

• Have MultistageChannelFilter design better filters. I found a paper on the subject which suggests that no more than four stages be used, but MultistageChannelFilter always tries to make as many stages as it can. The replacement strategy would actually look at the number of taps produced for a given stage design and choose the best overall structure. (This being a substantial computation, it should also be cached.)
• Generally improve the data-binding subsystem so it uses no polling or slower polling where it can.

[corpr8]

Thanks for this - I'll have a go with these enhancements - also, I might fork out for a more powerful host to run your awesome software :-)

[kpreid]

Reopening. I'm now using this to track the enhancements.

[kpreid]

As of commit 48bfbb7b87b87606d5a0c0eb6f5d869e6a9bc8bf (or see 7dae75f35ee4e3d06dc40f7cfaa80cf325323d05 for the end of that line of development), there is no unnecessary polling. Some cells are still polled, but only those where there really is a continuous stream of data (e.g. signal level meters).