Re: Distributing a gnuradio-flow diagram across multiple cpu's

[Marcus Müller]

Hi Anish,
On 16/10/2020 06.45, Anish Mangal wrote:
> I ran volk_profile, and maybe saw some improvement or could be imagining 
> things. Am I supposed to re-compile anything (gnuradio?) after I run 
> volk_profile or it is some kind of runtime optimization? Will this also 
> run on a mac osx?

You don't have to do anything after running volk_profile! It just 
benchmarks a couple of implementation, and stores the "best" one, and 
then when you run a GNU Radio flow graph that uses VOLK (which for 
example the "add" does), it uses that optimal implementation.

> There is always that scope - use a lesser sample rate, and pack all the 
> channels next to each other, but I'd rather not go down that road at the 
> moment. 

That's OK. If your channel raster is still fixed, and that raster can be 
a multiple of your audio sampling rate, you can use the PFB Synthesizer 
block [1] to efficiently put channels on that raster – no need to put 
them next to each other. All you have to do is use Low-Pass Filter Taps 
giving you a filter that has channel bandwidth, at output sampling rate.

I'm actually pretty surprised to see the Rational Resampler eat so much 
CPU here. Could you check whether "Interpolating FIR Filter" works better?

> I'd like to have some flexibility to move carrier frequencies 
> around. Another change I envision is the move up from a 8 bit SDR 
> (hackrf) to a 12 bit one offering more resolution. Because adding 
> multiple carriers will result in a final signal where even low signal 
> values become significant (as opposed to just conventional fm with 
> constant amplitude).

Ah, don't worry about that in your flowgraph yet, though: the dynamic 
range here should be large enough. Your single 8 bit sample doesn't have 
to yield high SNR for the low-power signals!

> "Another flowgraph could read the IQ file and send it over a ZMQ 
> socket with a pub sink (using ipc://) to the third flowgraph running 
> with ZMQ Sub sources, adding the streams, and then playing it out over 
> the hackrf."
>
> The application this is being experimented for will involve real-time 
> audio inputs from microphones unlike this flowgraph using wav files, so 
> wonder how Nate's idea of using zmq could be adapted to that case. 

Yes, sure, but be wary that if you have a lot of microphones and 
independent ADCs for these, you run into what large-scale studio 
equipment manufacturers have run into for years: the chance that the 
sample clocks of two independent ADCs are different enough so that you'd 
have to drop samples from the faster one to align the streams is small.
If you add *many* ADCs to that problem, it becomes harder. Probably not 
a big thing with modern hardware and moderate numbers of microphones, 
but distributed sample-rate-aligned systems are nontrivial.

> If 
> there is a small sample flowgraph I can experiment and build upon, I'd 
> love that.

GNU Radio comes with an example of the PUSH/PULL[2] mechanism; you'd 
look in /usr/share/doc/gnuradio/examples/zmq/zeromq_pushpull.grc 
(replace "/usr" with prefix where GNU Radio was installed to).

Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php/Polyphase_Synthesizer
[2a] https://wiki.gnuradio.org/index.php/ZMQ_PUSH_Sink
[2b] https://wiki.gnuradio.org/index.php/ZMQ_PULL_Source