[hpsdr] HPSDR software direction

[Ray Page]

I like the gist of Phil's idea. I think it has the potential to make the
effort of developers bear more fruit. For instance, if the DSP server
interface is defined (no easy task) then a number of "camps" can build
servers the way they think is best. By making the software architecture
modular, users can piece together "the best" collection of components for
their application. If I like GUI-C and my hardware supports DSP Server-A,
then I can have my cake and eat it too.

Not to minimize the effort required, but all we're doing is standardizing
the DSP in/out interface. The hardware enumeration capability would be
fantastic, but should probably be apart of the GUI function. I think the DSP
engine should be somewhat dedicated to the DSP task. Client software will
configure the DSP engine through a standardized command interface and tell
it the nature of the raw input data streams, what to do to those streams,
and the format of the data-out streams.

I don't know about the rest of you, but this approach liberates me, because
it gives me a black box with defined gozinta's and gozouta's, leaving me
completely free to implement the inside of the black box however I want, OR
to not worry about what's inside the box and work on the other stuff. It
should also make benchmarking easier. The "sever" can run on the same
computer as the GUI, or on a dedicated box on the network, allowing me to
tool around the house with my wireless laptop, which wouldn't have the
needed horsepower to do the DSP stuff.

-Ray KF5HNK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20100805/60e57ed9/attachment-0004.htm>