Software is hard, and worse is the next best thing to impossible to estimate reliably, real time software is an order of magnitude harder, realtime on a multitasking general purpose machine is harder again (And is just plain nasty to debug).
PCs provide a lot of cheap compute power, but low and deterministic latency is not their strong point.
Never underestimate the pain of going from a prototype to a product, especially when MS Windows is in any way involved.
Flex started as a sort of hacker platform. Gerald provided the basic VB core to get it working. Later, they picked up dttsp (in C) as the engine and VC# for the UI stuff. The idea was that dttsp would be a nice reliable open source signal processing core, and that the bazaar would provide enhancements both for the dsp and UI.
It worked fine for what it was. But the user base grew (very quickly) and those users were not SDR hackers looking to scratch an itch. They were hams wanting an inexpensive high performance radio to compete with the multikilobuck radios. I suppose you could say it was the transition from a prototype (the hacker platform) to a product (orders of magnitude more users than coders).
That said, Windows (while a pain in some ways) didn't make it horribly harder. Had they run under Linux from day 1, they wouldn't have had the transition: it would still be a hacker platform. More importantly, Gerald would never have built the first one, because he worked in VB, and that's a Windows only product. I think it was a great thing he did. He didn't get wrapped around the axle about needing a special DSP processor, or trying to link to some fancy DSP library, or even fooling with gnuradio. To say nothing of the absolute PAIN it was trying to get audio devices to work under Linux was back in 2003. He figured, hey, my PC is fast enough to do simple DSP in VB, why not build a radio. And he did.
ANd that motivated a horde of folks to get with the program and make serious efforts in PC based SDRs. Phil Covington had an idea to build a SDR, and got convinced that it would be productive to build high performance audio interfaces to improve the performance of the SDR1k, and that got a lot of people involved in other SDRs. There were a lot of bumps in the road there, too. The SDR1K existing, or more properly, the existence of PowerSDR which was flexible enough to support other hardware prompted the development of the SoftRock, a very cheap SDR using a crystal instead of the DDS.
What could be interesting is investigating the possibility of using a small dedicated compute board as a baseband processor for the anan/hermes radios, possibly itself with FPGA support or using CUDA or something, this would sit as a shim between the userland devices and create the the very high bandwidth I/Q data stream for the radios as well as doing the FFTs and suchlike, allowing the controls to run in a rather less time constrained environment.
I am thinking something like a TMS320C6xxx or SHARK, a Gb network port for the radios and a second network interface for the user network. The DSPs can handle the baseband processing without breaking a sweat, and can do it with negligible latency as they can work sample by sample in interrupt context rather then having to do blockwise processing like a PC does. As memory serves Hermes at least lets you select the amount of decimation in the CIC chain so it may well be practical to run at baseband bandwidths limited only by the network bandwidth to the radio.
Such things have been around for a while, and never got traction. DSP-10 for instance. The problem, fundamentally, is that there are relatively few people actually interested and skilled enough to fool with the DSP side of an SDR. So the sales volume of your radio will be small, unless there is "off the shelf" software that makes it work. Today, YOU could go out and build yourself an SDR with your processor of choice (use an eval board, like Bob Larkin did for the DSP-10). But then you're constrained to work with THAT processor, and whatever you choose, it won't be as common as an x86 based PC. Pretty soon, that processor will be obsolete, you'll be running the dev tools in emulation, etc.
For a more modern, and fairly well supported, device, take a look at Matt Ettus's USRP (also available from National Instruments). It's a nice hacker platform, has an FPGA, hooks up to gnu-radio. Hundreds of them have been used by undergrads and grad students for senior projects, thesis projects, and PhD dissertations. They're also used a lot in industry, and as "cell site emulators" for a variety of purposes, some good, some evil.
This is essentially where the 6000 series is trying to go, but I want something hackable, including having the VHDL/Verilog be hackable, however good the supplied API may be, sooner or later you will hit something it will not let you do, and that sort of defeats the point of an SDR for me.
Yes.. the USRP is what you want. The F6.xK or the F5K or the F3, etc. are what the average ham SDR buyer wants: a turnkey box with easily installed software upgrades provided "by others". I'm sure others will spring up in that market. There are SUBSTANTIAL challenges: software development costs are but one (since "open source" did not provide a free (as in beer) option); there's also a host of regulatory issues. It's one thing to sell a box o'parts to a hacker in small quantities; the FCC is going to let you do whatever you do, just like if you cobbled together a rig using that surplus PTO and those 6146 tubes you got from an estate sale, with some sockets you made by drilling holes in some beer coasters.
However, start selling a "box" with a "user manual" and such, and they're going to ask questions like "how do you block reception of cellular frequencies?" and "how do you prevent out of band emissions?" and "could you demonstrate that your spurious signals meet good engineering practice"
That's the "prototype to product" transition you mentioned, in real life..