[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block fo
Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Wed, 30 Oct 2013 09:28:24 +0100
> I've added basic sample rate awareness to gr-fosphor via constructor
> parameters and a set_rate() call. The GRC blocks now take a sample rate
> parameter as well. The sink also creates an appropriate legend (kHz, MHz,
> etc.) and applies it to the plot. I've tested it with WX, Qt, and GLFW
> versions of the sink.
Nice, but unfortunately I'm working on my own version of this.
I wasn't really happy with the current set_range. So I'm doing a bit
of refactoring. Basically the cl_state and gl_state struct will be
kept around for strictly CL/GL stuff but most method will get the full
fosphor struct as argument and I will put shared stuff and things not
strictly CL/GL there. For example the sample rate is useful in CL to
dynamically adapt the batch size and the time constants of fading to
ensure low latency in low bitrate case and performance in high bitrate
cases. And there is some similar stuff happenning with other types of
set/get I wanted to put in so I decided to do the refactor first.
> Sylvain, if you'd like to pull it back, it's in a Github repo at
> address@hidden:bistromath/gr-fosphor.git. I've also added a CMake check for
> the Python OpenGL bindings, as I somehow managed to not have them installed
> on my new machine.
Interesting. Did that actually prevent build ? What was the symptom ?
A choice I've made (albeit a possibly questionable one) was to only
check for things required at build time.
For example, I don't check you have WX Python installed either ... if
you don't the import will fail in python but be caught and the sink
will just not work but shouldn't prevent using the others and if you
want the WX one, just install the dependencies afterwards and no need
to rebuild gr-fosphor.