03-04-2020, 12:01 PM
(This post was last modified: 03-04-2020, 02:30 PM by ab1jx.
Edit Reason: Peter Onion, OpenGL, Vulkan, waterfall
)
The CPU intensive part of a GUI SDR program is the GUI itself, all the redrawing that the CPU is doing. Find a way to turn that off, since you don't need it once you get a signal tuned in, or use the GPU to do that, or use rtl_fm. I've been fiddling with trying to write one for a couple years, using librtlsdr to deal with the USB and dongle. I've done the graphics at least 3 different ways and it's always the bottleneck.
Debian Buster (and later) has Cubic SDR in the debs, just click on it in Synaptic and it installs and works. Both that and GQRX have tons of dependencies and neither is as efficient as it could be.
This is from 2014 by a Peter Onion https://www.youtube.com/watch?v=0IZxzm4R1bo It's an SDR program of his running on a Raspberry Pi. The graphics are done in OpenGL ES where the waterfall is actually a rotating texture. It's not a full-fledged SDR program because it's just a panadapter that's showing the IF (Intermediate Frequency) output of some other radio. I don't know what ever happened to it. Notice there aren't widgets like text, frequencies, pointers. I think you'd need to put the spectrum and waterfall into a window and put widgets around it. The OpenGL ES would be rendering directly to the framebuffer and using the full screen, something like GLFW would make it more manageable.
Using OpenGL ES for this is kind of backwards and not very efficient but it sort of works. It would probably be better to do it in Vulkan. 2 - 30 times per second you get a bufferfull of data which you need to scale and plot as the spectrum at the top. Then with that same data you convert peak heights to colors and draw one line. The waterfall is just copying that line down 1 pixel for each batch of data. The GPU has at least dozens of processors that could be handling that.
Debian Buster (and later) has Cubic SDR in the debs, just click on it in Synaptic and it installs and works. Both that and GQRX have tons of dependencies and neither is as efficient as it could be.
This is from 2014 by a Peter Onion https://www.youtube.com/watch?v=0IZxzm4R1bo It's an SDR program of his running on a Raspberry Pi. The graphics are done in OpenGL ES where the waterfall is actually a rotating texture. It's not a full-fledged SDR program because it's just a panadapter that's showing the IF (Intermediate Frequency) output of some other radio. I don't know what ever happened to it. Notice there aren't widgets like text, frequencies, pointers. I think you'd need to put the spectrum and waterfall into a window and put widgets around it. The OpenGL ES would be rendering directly to the framebuffer and using the full screen, something like GLFW would make it more manageable.
Using OpenGL ES for this is kind of backwards and not very efficient but it sort of works. It would probably be better to do it in Vulkan. 2 - 30 times per second you get a bufferfull of data which you need to scale and plot as the spectrum at the top. Then with that same data you convert peak heights to colors and draw one line. The waterfall is just copying that line down 1 pixel for each batch of data. The GPU has at least dozens of processors that could be handling that.