[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gnuradio-companion and multithreading

From: Andreas Ladanyi
Subject: Re: [Discuss-gnuradio] gnuradio-companion and multithreading
Date: Sun, 25 Jan 2015 19:22:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Hi Marcus,
Hi Andreas,

GRC is already as multithreaded as GTK applications can generally be --
I think the bottleneck here is really your Bananapi's CPU, its RAM and
its graphics card driver.
If i stop the drawing of all the graphs in the compiled GNU Radio application, i could change parameters like the volume or gain with the sliders/text boxes now.

The next was to decrease the sample rate of some blocks by adjusting the decimation.

I could not reduce the sample rate of the RTL block below 1 Msample. The testing tool told me that sample rates below 1M are invalid for the RTL stick. So i think the RTL source block needs the most CPU time.

All this changes reduced the overruns a lot. The CPU load decreases about 20 % to about 170 %.

This application works in general.
To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underwent optimization for
exactly this application -- low cost embedded media playing linux GPIO
bitbanging computing. Not general purpose GUIs like the GRC.

Generally, the most sensible approach to using such devices with GRC I'd
say is to run GRC on your "real" PC, and transfer over the resulting
python program to your embedded device. Please don't expect wonders from
the signal processing performance of a dual core ARM processor --
there's only so much FLOPS you can get out of silicon...
Ok, and which processors do you suggest in general for signal processing ? Which processors are optimized for signal processing ?

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]