Re: [linrad] RE: svgalib problems

[Edson Pereira <edson@xxxxxxxxxxxxx>]

Hi Lief,

On Mon, 6 Jan 2003, Leif Asbrink wrote:

> It would solve many problems but it is above what I can manage myself.
> It seems to me the new APIs require some programming skills that I do not
> have and that would be extremely difficult to accuire at my age.
>

Lief, after certain age we don't get older only wiser! :-)

> I can do conceptually simple things like coding assembly to use the
> smart multimedia instructions well even if it leads to complicated code.
> I can not do conceptually difficult things like understanding C++ and
> its generalised objects(???) even if it probably leads to simple code. 
> 
> The thing is I am not a programmer. I work with computers like I work
> with the soldering iron and the oscilloscope and spectrum analyzer. 
> Adding components one by one while constantly watching the resulting 
> waveforms and spectra.
>

Components are really nice. In splitting some functionality, we could also
take advantages of a component-based implementation in software. 
 
> > I have mentioned this before, but in order to simplify things in the long
> > term, may be Linrad could become a headless application. The user
> > interface would be an independent application communicating via some IPC.
> I have no idea about the implications of this. I do not even know what
> IPC stands for. I tried to read a little about SDL, Mesa and GTK.
> Completely unsucessfully:-(
> 

They do indeed have a steep learning curve. I personally preffer Qt since 
I can prototype things quickly with the design tools, but it is not 
necessarily the fastest graphics API around.

IPC is InterProcess Communication. Shared memory, pipes, sockets,
semaphores, etc. Apologies for the jargon.

> Maybe Linrad could have its own screen image, a memory area 
> where I can set pixels rapidly. Then some different application 
> would be responsible for fetching the entire data area something 
> like 10 times each second. 1024 * 768 * 8 * 10 = 63 megabit 
> per second. In case it is done with dma on some bus that is 
> not much used, it might not cause any problems at all to Linrad. 
> I am totally ignorant here but it seems to me the modern PC 
> has several busses(??) 
>

This is a nice description for a shared memory implementation. Two or more
processes share a memory area. Normally, one process is a producer of data
and the other is a consumer. 

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.

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.

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:

lock_fft_shared_memory();
memcpy( fft_shared_memory, new_fft_values, size );
update_fft_update_counter();
unlock_fft_shared_memory();

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.

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. 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.

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.  

73,

-- Edson






LINRADDARNIL