RE: [linrad] RE: svgalib problems

[leif.asbrink@xxxxxxxxxxxxxxxx>]

Hi Edson,

> This is just loud thinking:
> 
> Linrad could use an abstract concept of widgets, in which every input and
> output could just be a variable in the shared memory structure. For
> example, the FFT output could be an array, and input/output controls a
> char, int, float, etc. No APIs, everything just normal C variables (which
> are shared).
> 
> An application could just read (or write) to the shared memory space.  
> Things could be done asynchronously, so that if a user interface
> implementation is slow, it would not block Linrad, but there should be a
> mechanism to indicate that data is being lost. May be un update counter
> that gets incremented every time an update occurs.
I do not know. In a way this is how Linrad already works although it
all is contained in a single program.

> In the case of the FFT, only the new values could be updated. It would be
> the responsibility of the user interface to provide the waterfall, etc.
It is not so easy. Linrad uses large cyclic buffers and sometimes new
data is calculated from information scattered over large memory areas.
I think it will be best to allow the user interface program to do very
simple things only. 

> In order to prevent data corruption, writes to the shared memory area
> would be protected using semaphores. For example to transfer a new set of
> FFT computations:
It is already arranged in such a way that everything is in circular buffers.
The user interface is responsible for keeping its own pointers to protect
the area it has not yet processed and the routine creating the data
has its own pointers that indicate where writes may happen.
 
> lock_fft_shared_memory();
> memcpy( fft_shared_memory, new_fft_values, size );
> update_fft_update_counter();
> unlock_fft_shared_memory();
I am afraid unnecessary memory copy will destroy the performance of Linrad.
I do not see why there is a need to do it.

> This would prevent the user interface from fetching data while it is being
> written.
> 
> Look, and feel of the screen instruments would all be implemented on the
> GUI side. Linrad would be doing only DSP making the results available and 
> listening to controls via shared memory.
I have no idea if it is possible from a performance point of view.

> As an intermediate step (in which things could be designed and tested),
> Lief could still use SVGAlib, but in a separate application talking with
> Linrad via shared memory.
If I knew how to have two applications share memory this would not be
very difficult. It might even be a simplification.

> Once things are defined, then we could document
> the shared memory data structure and usage and start implementing the user
> interface in X or any other GUI API.
It is not quite that easy. New functions will require specific support 
from the GUI. Linrad is not just a dsp program. The operator can modify
it on the fly in many different ways and there is a very large (and growing)
number of things that the user interface must do.

> What do you think, Leif?
> 
> I would really like to help in any way possible to make Linrad prosper
> without risks of external software or library dependencies.  

As it is now, Linrad needs a few fast routines,
setpixel(x,y,colour)
drawline(x1,y1,x2,y2,colour)
writetext(x,y,text)
getmouse (to provide coordinate and button status)
getbox (get data from screen, does not have to be fast)

A few more svgalib functions are used but I do not think I really need them.
Some alternative way to get these functions into a C program would solve
the svgalib problem for now.

Actually splitting Linrad into independent modules is something 
I would prefer to leave for the future. It is obvious it can be 
done and that one could split the task on several computers but 
it is not quite along my line of interest.

I want to run Linrad on a single dedicated computer which is 
carefully made free from emitting RFI. Linrad and the hardware 
I make to use with it will provide RX performance well above 
anything else and my personal interest is the radio receiver, 
not the computing itself.

There is the GNU radio and several other projects that are more
professional from a computing point of view. I think it will
be possible to take the algorithms of Linrad and move them into
other software packages. Rather soon a loss of processing efficiency
will be insignificant and then many of the difficult things in
Linrad will be obsolete.

Is it possible to replace svgalib with something else just to get
a few primitive screen functions?

73

Leif  /  SM5BSZ



LINRADDARNIL