Testing an GRC project runs nearly 200% CPU

Hi,

iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The
application starts. The tuned radio station sounds clicking. Changing
any parameter in the GUI is very difficult/slow.

top tells me a memory usage about 20 %. CPU usage is nearly 200 %
(bananapi has 2 CPUs). At any webside i read that working with no
throttle blocks could run a CPU to maximum. In my project which iam
testing i see no throttle blocks. I am not sure if that could be the
reason because iam working on the bananapis real hardware ?

Is there something wrong with the sample rate ?

Andreas

Post a screenshot of your flowgraph. Sounds like a sample rate mismatch.

On Fri, Jan 16, 2015 at 8:38 AM, Andreas L.

Hello Andreas,

you never need a throttle block when you have hardware that
limits/defines your real-world sampling rate; in your case, it’s your RF
hardware and your sound card.
Aside from things like implicit resampling in the audio card driver
infrastructure, it’s absolutely possible that your bananapi is simply
not performant enough to do GUI, signal processing and audio playback at
once.
The question is: Does the same application work sufficiently well on a
fast PC? Do you see any over- or underrun warnings on your console?

Greetings,
Marcus

On 01/16/2015 12:58 AM, Marcus M. wrote:

Hello Andreas,

you never need a throttle block when you have hardware that
limits/defines your real-world sampling rate; in your case, it’s your RF
hardware and your sound card.
Aside from things like implicit resampling in the audio card driver
infrastructure, it’s absolutely possible that your bananapi is simply
not performant enough to do GUI, signal processing and audio playback at
once.

Resamplers are often performance killers.

M


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Hi Andreas,

that’s kind of interesting, because if it works on a PC, I’d say it’s a
performance issue; if you don’t see aU (audio underruns) or some osmosdr
warnings, then I’d say it’s not.
What one does in this situation is both running a process-based cpu
usage tool; I recommend “htop” (which is like top, but actually a lot
nicer). Do you have another process suddenly consume CPU? Does it look
like it’s pulseaudio (that would be the implicit audio resampling
issue)?
If, what I presume, you only see two python processes consuming 100%
each, you will need to dig deeper. There’s a tool called “perf” [1],
which, when run as “perf top” as root will let you introspect CPU usage
per method, including kernel routines.
Both perf and htop are available as packets for many Linux
distributions.

Best regards,
Marcus
[1] Tutorial - Perf Wiki

Hi Vanush,

attached you could find the screenshot of the flowgraph.

Andreas

Hi Andreas,

Yes i remember a lot of such characters on the console. Is the sample
rate of the audio device to small ?
in some way or another, yes.
Explanation: A sound card consumes a fixed about of samples per second
(e.g. 48,000), that we shall call f_sample,soundcard
You need to supply these in time, and if you don’t, your sound will be
choppy and you’ll see aU.

The fact that you’re not doing that in time can have two reasons
(actually three reasons[1]):

  1. systematically: You take your RF samples from your SDR peripheral,
    and you process it, decimating it to a fixed rate of f_sample,RF <
    f_sample,soundcard.
  2. computationally: although your theoretical flow graph does the right
    thing, ie. f_sample,RF / decimation == f_sample,soundcard, your computer
    can’t process these samples in time, and your sound card has to wait for
    these samples. Since the real world time keeps running on, it can’t
    produce sound.
  3. real physics don’t like anybody: both the sound card and your RF
    hardware have oscillators from which they generate their sampling rates;
    these oscillators will neither be perfect nor will they be coherent, so
    inevitably there will be some mismatch between the expected and actual
    sampling rates. However, these offsets tend to be small and would
    usually not lead to massive accumulations of audio underruns.

So, since the same application works on a faster machine, I’d say it’s
2). What you could check, though, is that the sampling rate you set in
your audio sink is actually supported by the hardware, and try with
different values (e.g. 44,100 Hz instead of 48,000, but that’s about it
when it comes to usual sampling rates), but you’d of course have to
adjust your decimation between RF hardware and sound card accordingly.

Greetings,
Marcus

[1] No one expects the Spanish Inquisition - YouTube