Jim:
You are exactly where we are. In the early days of this when Gerald
produced the VB code, his company was like many startups, he was being
cautious. He was not about to allow a few folks "take over his
company" and he had produced the VB console. Gerald says he agonized
for months whether or not to release the source for VB and then whether
or not it should be GPL. I hope he feels he made the right choice.
So, you are right. You are seeing the legacy from the VB code. Many
feel very much let down that it did not stay simple and accessible as in
VB. That had to be balanced against Gerald's desire to build a company
that would last more than a 3 board kit shipped without the necessary
hardware to make it stand up! Several of us bought in to this SDR in a
big way and we went to Austin in person and talked Gerald into going a
new way. He agreed to produce a console based on a multithreaded model
that Frank and I went to Austin to sell him. He hired Eric, and we set
off. A couple of months later, we have PowerSDR 0.0.1 alpha. It has
been a single process 'til now. Around the time of PowerSDR 1.3.6
Frank had taken all of the DSP code underneath and produced a coherent
body of code using some neat macro's at its heart and achieving awesome
efficiency. We found a couple of problems with ring buffering, and I
built this multithreading thing under Windows that ran under Eric's GUI
that had some seriously bad thread stalls in it that took months to find
and sort out. I really did put my dunce cap on for some of the stuff
that went on.
It has been an evolutionary process and we are at the place where the
SDR stuff needs to be easier to allow others to play developer. It needs
to be moved to development with free tools where possible so even more
can play. If we do all the stuff except the GUI with free tools, as
separate processes, many more people can play and we can keep very
similar code bases. Jointly, we have all come a long way in 3 years.
On to 1.7:
Once we have the "Virtual Radio Central Command" working and playing
radio commander central , this multiple process model is likely to be
the best model. This is the model Frank designed for Linux from the
smouldering, festering, heap of rubble that was the first DSP code
(mostly my fault). Together Frank and I produced the modules that are
in the library libDttSP.a and .so for the smouldering heap of rubble. It
is in the Linux stuff and at the heart of the windows stuff but
seriously refactored by Frank. There have been differences creep in as
I developed dsp primarily on Windows to keep Flex going towards a long
term goal. Many of the later ideas have been suggested by others and
almost all of them were Windows users who wanted it done for Windows.
It is a natural consequence of Winblows domination of the world. These
differences between the dsp (not the process/vice thread) will be
resolved next week. From the smouldering festering heap, Frank
developed the entire threading model, the data structures, the macro's,
the ring buffers, etc. on Linux. We are all profoundly grateful I am
sure and we should be. We are just about to really see that take off on
Linux as the separate process model gets fleshed out and then be brought
back to Windows I think. Should we do this, it will enable anyone to
write their own console on top of the running sdr code or place their
own special purpose app on top of it with or without a GUI, etc. Gerald
anticipates commercial customers that will want the sdr to run under
Linux on servers. If we bring this model to bear, it will allow us to
build shared memory interfaces under Windows that to all underlying
console processes look exactly the same as they would under Linux, BSD,
or Mac OSX. The SDR DSP software, mostly done in sdr.c and the
functions it calls, does not care how they get data. They only care
they got it somehow.
We have divorced long enough to get stability on one (Windows) so Gerald
would have a stable usable product that he can support and use for a
long time and it also convinced the independent Linux users and
developers such as Pereira and Melton to proceed with a stable base. It
is hard to imagine how much more pleased Frank and I could be than to
have two super stars like Pereira and Melton take up this challenge. We
need to accomplish a marriage that makes sense where we can in fact have
one process for doing dsp on windows that is very similar and uses
similarly mechanisms to Linux, Mac, BSD, etc.
We can do this now as we proceed to 1.7 on the next couple of months.
Thank you for taking the time to do this investigation and
documentation. It has been extremely helpful to me.
I did a major cleaning on the dsp library for windows and next
Wednesday, Frank and I work from breakfast until ? to get our complete
act together on DttSPv2. We may not finish, but we should get close.
For the linux folks who have been following the model, a few minor
things will have changed. John Melton has said that he will adopt
DttSPv2 for the Java console. Phil C has said he will adopt it for
HPSDR. With you and all of these folks looking over our shoulder (and
kicking our rear), we are getting disciplined.
Enough old history,
Bob
Jim Lux wrote:
At 06:31 AM 2/22/2006, Robert McGwier wrote:
These files were the proximate cause of our fork for development
purposes.
winmain, as in windows main file, is the "main" program for the
constructor, destructor, threading control, etc. in the PowerSDR
software.
main.c contains all of the same stuff. the normal c language main,
and none of the windows clutter and is used to construct jsdr from
update.c, sdr.c, and the myriad library modules. Most of these
modules build libDttSP.a and libDttSP.so...... on *nices.
Bob
So, then, in the windows model, everything is linked into one giant
process? As opposed to a windows interface process that talks to a
windows dsp process?
Considering that it's not all that hard to have windows console
applications, and to have another process start it up, why not do it
that way?
Seems like you could keep the windows dsp and linux dsp forks "more
similar" with that approach?
(It's not like the dsp thread needs all the stuff from MFC, etc.)
Or is it just historical, coming from the original VB software model?
Jim.
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
