|
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,
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.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.
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.
Ok, and which processors do you suggest in general for signal processing ? Which processors are optimized for signal processing ?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...
Best regards, Marcus
regards, Andreas
[Prev in Thread] | Current Thread | [Next in Thread] |