[linrad] Re: Mandriva 2006.1-0.3 Free

["sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Richard,

> > You are totally missing the point. I am trying (very hard) to make
> > you understand that it takes some time for others to adapt to the changes
> > different companies choose to make in their kernel or file systems.
> 
> No Leif, I'm sorry to say it is the other way a round , this "argument" has continued
> several years off and on already.
This is just insane.
Linrad depends on things (svgalib and OSS) that are maintained by few
people. They need time. It is as simple as that. 

> When you produce a distribution, whether linux. MACOS of even windows, it has to work for the
> majority.
>   When you get one man one band delevopers not following the direction thedistro is moving, causes 
> major problems.
> OSS has been a pain for a long while, the only direction that's going now is to extinction, its a 
> software dinosaur.
> Alsa drivers for the delta44/66 cards work, Alsa is built into the kernel, its now the standard.
This is your statement. It may be correct now but I have heard it 
from others long ago when it was not correct.

> The other danger with OSS is that is an off shoot of a commercial body.
> 
> Leif why not a long last drop the supporting apps for linrad that have just one maintainer,
This is a major task with which I am working now (since over one year). 
The way I do it is by a complete structural change into a multi-threaded 
structure. I am doing it the most efficiant way of my understanding, 
but it is a complicated thing.

> Step back look at linrad, the functionality is there, you know what your doing, and change its 
> reputation from a ball breaking app to get going, from one that's too specialised to use, and the 
> worse for moderm Hams, one that's unattractive and not easy to use.
There are other softwares for those hams who want fast happiness.
Linrad is far too general (not specialised) to be easy to use. I am
going to keep it that way because my main interest is better 
performance through better algorithms. Those who want something
that is easy to use should choose Winrad. There are some
performance differences though, but not all operators are interested
in very weak or heavily disturbed signals.

> Please look at running with ALSA and in an X-window , Xorg seems more  popular than xfree86, and if 
> I remember right that was only due to the xfre86 on man band wanting more acknowledgement for the 
> work he'd done.
> 
> Have a look a Alberto's graphics in winrad, which runs in Crossover office better than wine.
Hmmm, the computer I have Windows on, a Pentium3, 600MHz, can not run Winrad
at a sampling speed of 96 kHz. I have to set the sampling at 48 kHz and then
the CPU load is about 75%.

Linrad runs happily two channels simultaneously at 96 kHz with a CPU usage
just below 50% under Windows on the same computer, but under Linux with
svgalib the same computer runs two channels simultaneously at 192 kHz
at a CPU load of 81%. Note that CPU load increases faster than the sampling 
speed.


It seems I should explain a little what I try to do and why.

1) Linrad is old. I started it before even Pentium computers
were available. The first processor was a TMS320C25. In the first
phase Linrad was a dedicated tool for efficient use of X-pol
antennas for 144 MHz EME. Max bandwidth was 3 kHz.

2) When the first Pentium MMX became available I moved everything
from my home-made hardware into a PC computer. This was still a
dedicated EME-ers tool with a bandwidth of 20 kHz under MSDOS.

3) Having the EME-ers, tool I started to get an interest in other
usages. The MSDOS package was highly optimized for the hardware,
with fixed memory allocations for everything. The first Pentium 
MMX was not very fast. My interest in using Linrad as a tool for
analysis of various things made me want a VERY flexible system
with more bandwidth. I moved to Linux. At this time the only
possible solution was svgalib and OSS. The ALSA project was not
yet started.

4) As you can read in some now very old places, Linrad is aimed
to be a software for a modern digital receiver that samples at
VHF frequencies, does a digital down-conversion and presents
a fairly large bandwidth to the PC computer. That is my primary
focus. I want a bandwidth of at least 1 MHz into the PC so that
is why I am so concerned about CPU usage. Such hardware is not
available yet and I expect it to take several more years until
I have it in my hands. What comes nearest today is the SDR-14. It
can give about 180 kHz of bandwidth, but the dynamic range is
not what I look for. The baseband is limited to 16 bits by
the USB interface and the A/D converter suffers from intermodulation
pick-up from the digital output of the chip.

5) In my long term project I found it necessary to build hardware
by which I can simulate important aspects of the expected 
future digital hardware. That is the WSE converters. These
units are actually overqualified for normal amateur usage, they
are precision instruments, hand made in a small quantity.
I have made them available to those who understand they want
them with a hope that this will bring some feedback from
amateurs with a genuine technical interest and/or a genuine
interest in hearing signals that could not be heard without
these tools. I also hope some WSE owners will use their 
systems to measure interference emissions from amateur transmitters.
The badly designed ALC systems of modern ham gear is often the
main source of interference on todays ham bands. Transmitters
are generally not as good as receivers because nobody makes 
measurements on modulated transmitters. WSE owners can change
this.

6) Both hardware and software develops and the only possible solution
from before starts to become a problem. You are absolutely
right in this - but you are totally ignorant in what it
really means. This very problem is at my focus right now
and therefore I am separating OS-dependent things from the
actual signal processing. I am also restructuring the code 
to make it multi-threaded because this will become an advantage
in the future even though it degrades performance on elderly
computers. I started this about one year ago and it is not
anywhere near completed yet, but the now old Linrad-01.35 can
be used in the meantime by those who are motivated enough.

7) Linrad is free software from start. I am fully aware it
is too advanced to suit the average amateur. It has never been
my intention to make a mass product. What I am trying to
do is to show what is possible in order to challenge others
to use whatever they find interesting to improve their products.
Modern transceivers use DSP for filtering. They could implement
efficient noise blankers if they had a pressure from the 
market to do so. When Winrad is equally good as Linrad in
blanking close to a strong signal, large numbers of amateurs 
will realize what is possible. Why should then prospective
buyers of IC7800 or FTdx9000 accept a much worse performance?

> Come Leif if you coped with the change in which side of the road you drive on back in the 60's, it 
> is so difficult to look at the areas of linrad that would really get it well known and heavily used.

The bottom line is that you have misunderstood everything.
My background is in physics. I have a genuine interest in
the processing algorithms themselves. I hope my work will
give inspiration to others.

Certainly the time has come to change for ALSA. Not the OSS-
compatible version of ALSA which has never been working 
properly as far as I know, but to the genuine ALSA interface.

In the new structure of Linrad-02.xx this will be a trivial
task for anyone who can use C++. There is a need for a subroutine
that opens sound devices and an associated set-up. That is all. 
The Linrad dsp code only uses a single call to the sound
system, a blocking read statement. All ioctl and buffer
watching that was necessary in the single-threaded code
is gone so now it does not matter at all for the dsp code
even whether it runs under Linux or Windows.

I hope someone else will be kind enough to supply a C++ interface
for ALSA some day. I do not want to use my time for this.,
I want to do signal processing.

The same goes for X. I do not need it - so I do not implement
it. It is as simple as that. Anyone who is interested can
make an X version of Linrad-02.xx without much work. In case
it is done in a way compatible to the format I have set up I
will happily include it in the standard distribution of Linrad.

In the meantime my statement is true:
> > You are totally missing the point. I am trying (very hard) to make
> > you understand that it takes some time for others to adapt to the changes
> > different companies choose to make in their kernel or file systems.

Your careless denial of this fact could be misunderstood.
What you really say is that it is not a good situation to be
depending on non-standard packages. That is quite another thing.
Linrad IS depending. For VERY good historical reasons. Linrad
will continue to be depending on OSS and svgalib for quite
some time.

I AM working on it since over a year and in the future Linrad 
will become easy to adapt to whatever graphics or sound system 
you like. My guess is that it might take one or two years until it
runs with ALSA under kde and gnome.

73

Leif




#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL