[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe,
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Tue, 09 Mar 2010 12:51:14 -0800
Vincenzo, I read your new teaser on Memory Acceleration. Time/memory
tradeoffs, yes, have done that. Recursive table aggregation, OK.
Algorithm segmentation, sure. I am still looking forward to the real
paper, when it gets released.
But I have a structural question. We've now seen two major projects
that use the USRP, libusrp, and the general software signal processing
paradigm of GNU Radio. But they both totally abandoned the GNU Radio
code base. Both SR-DVB and OpenBTS wrote their own code from scratch,
even though major parts of the computation could have been handled by
GNU Radio processing blocks. Why?
Does something about the structure of GNU Radio doom it to only be
used in "experiments" and "demos"? Is the problem in the complex,
multi-language realtime high level structure, or the low level block
processing structure, or somewhere else? Perhaps it was a legal
issue, that both projects initially thought they didn't want to
license their code under the GPL? (OpenBTS has since changed its
mind.) Will techniques like memory acceleration be usable in signal
processing blocks embedded in the GNU Radio signal processing
framework? Or does its basic signal flow structure make it an
inappropriate host? If so, what should we do about this?
Have we made it too hard to use GNU Radio as a subroutine library for
the functions close to the hardware (like tuning and demodulation),
letting them be called from a custom main program that includes custom
code for parsing and managing higher level protocols?
How can we make it simpler to build big projects on GNU Radio and
produce reliable and efficient production-quality programs?