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. <br>
<br>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.<br>
<br>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.<br>
<br>-Ray KF5HNK<br><br><br><br><br><br>