On Tue, Sep 4, 2012 at 7:51 AM, <mle...@ripnet.com> wrote: > ** > > On 04 Sep 2012 10:48, Tom Rondeau wrote: > > I'm not sure that I consider what they do an abstraction layer. They just > switch between a handful of devices. Tom > > Anything that reduces/eliminates the need for multiple flow-graphs to > support different devices with a similar "high level" interface is a good > thing. For that, gr-osmosdr works quite well. > A useful abstraction layer would provide an 'upper API' that user code would rely on for providing a stable, common interface to program to, while also providing a 'lower API' to device manufacturers to register with (at runtime library initialization or as loadable modules) to inform GNU Radio of device capabilities and to perform actual API calls.
The challenge is in coming up with an upper API abstraction that adequately covers the common functions of device discovery, configuration, naming, streaming vs. burst data transfers, metadata, multiple device support, synchronization, etc., for a variety of devices, but that also allows users to get at any vendor specific features that don't fit into the abstraction. I could certainly see developing a 'gr-sdr' component that provides the upper API source and sink blocks and allows other blocks or libraries to hook in underneath. That part, though, is fairly mechanical in nature (pluggable APIs go back decades). I'd want to see a well-thought out upper and lower abstraction that people are happy with before writing any code. Johnathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
