I absolutely agree with you. There are also other completely unrelated issues that keep coming up like Linux, python and x11. But I don't think there's any great harm in ending a topic by ever-so-gently pointing people in the right direction.
On Thu, May 9, 2019, 22:05 Marcus D. Leech <patchvonbraun@gmail.com> wrote:
_______________________________________________On 05/09/2019 02:54 PM, Albin Stigö wrote:
I'm going to suggest, ever-so-gently, that discuss-gnuradio, and Gnu Radio in general aren't the places for learning C++. There are forumsEvery instance of a block is an instance of the c++ class but like Nick says all your variables are static and not member variables. Those need to be declared in the header. Your two block instances are referring to the same variables and that's why things get messed up.
"A tour of C++" by Bjarne Stroustrup is a good refresher on C++.
--Albin
already for that.
I'm saying this only because in the 15 years (!!!!) I've been involved with Gnu Radio, I see an alarming number of cases where the
intrepid Gnu Radio developer actually doesn't have much in the way of programming experience in the underlying languages used,
and arrives here, nearly-certain that their problem is GR related, rather than an improper use of the underlying programming language.
My guess is that other specialized-framework environments have the same issue. Fortunately, most people here are helpful regardless.
But it shouldn't be a growing *expectation*, IMHO.
On Thu, May 9, 2019, 20:46 Nick Foster <bistromath@gmail.com> wrote:
It looks like you've declared a bunch of static variables within your block's namespace. Those variables (including pointers!) will be shared with every instance of your block. This is Bad News. Those variables should probably all be declared in the header as class member variables.
_______________________________________________On Thu, May 9, 2019 at 11:43 AM Brad Hein <linuxbrad@gmail.com> wrote:
_______________________________________________I'm running into a strange issue with a new flow graph [1] I'm working on that uses a custom C++ block [2] that I built. The block takes input samples, performs some DSP, and outputs modified samples at the same sample rate.
When the flowgraph has a single instance of my custom block enabled, it works fine. But when I enable a second instance of the block in a separate second usage, (think stereo sound, one per sink channel) it acts very unexpectedly - output samples are wildly inaccurate and distorted.
My perception is that the two instances of the same block seem to be sharing some part of their memory namespace and as they modify/store variables they are doing so in some sort of shared namespace or memory segment.
Is it possible for two blocks to corrupt each other's memory? I can't think of any other explanation for the two streams working fine individually, but when both are enabled at the same time the output is garbled. I've tried all sorts of things like tying them to the same source block, removing the upsampling/downsampling, adding a delay to one, etc. with no luck.
[1] "Flowgraph with two parallel streams both using the custom block pq_rails": https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc
[2] "pq_rails (Custom block) source code": https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment