On Sat, May 28, 2011 at 18:23, Marcus D. Leech <[email protected]> wrote: >> Cool! It would be truly great to see a simplified example of this in >> the GnuRadio repository, and at least somehow mentioned on the wiki. > Yes, I suppose it would. I'll put it on my list, but so many other > things to do :-( > >>> The other "trick" that I use is to use the XMLRPC server stuff that Josh put >>> in GRC--it allows you to set flowgraph variables from an >>> outside program, which is really great! >>> >> Hum. Any examples? >> >> I also wonder - have you quantified overhead of those methods - in >> latency, jitter, memory, etc? >> >> > Well, in terms of the FIFO I/O, they're pretty-darned efficient in > Linux, at least as efficient as disk I/O, > although since FIFOs (named pipes) are implemented in kernel memory, > they're typically a lot > faster.
Problem here is that FIFO's are not very well suited for real-time operation, IIRC. Have you tried a shared memory and shared signals across applications? > I've never needed the XMLRPC stuff to "go real fast", since I typically > use it to modify flow-graph > parameters that change infrequently. One of the things I use it for > in one of my applications that I > did for a customer is for active RFI excision for a science > application. The flow-graph produces > a spectral estimate which is sent over a FIFO to an external program > that analyses the spectrum, and > then, if necessary, sends back parameters for a multi-notch filter > into the flow-graph. Good idea. With only one problem - XML is a bit of overhead for real-time application messaging :) I wonder - have anyone considered using Google's Protocol Buffers or a similar messaging scheme with fast serialization/deserialization? http://code.google.com/apis/protocolbuffers/docs/overview.html -- Regards, Alexander Chemeris. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
