On Sun, 10 Nov 2002 ilya@theIlya.com wrote:

> First one is that handling of MSP code has to move out of program into
> library. Since only library maintainers will be able to write MSP code,
> no need to bother end-programmer with knowledge of it. Ideally VICE
> will be completely opaque to end-programmer.

I don't agree. What would be left to 'end-programmer' to program
anyway? :) I think the lib should be a mean to access VICE functionalities
easily (and through a well defined API), and not be restricted to
providing a few functionalities we'll implement (like for example JPEG2000
decoding). 
	Now that doesn't mean we shouldn't provide a few applications as
well (like a JPEG2000 decoder), with sample MSP code. But the MSP code is
specific to each application and thus should be in the application.

> One was to put it in files, and have library load it as nessesary.
> This is certainly easiest way to debug msp code itself.

	Yes. I was thinking of plugins, i.e. build shared libraries out of
the msp code with two exported symbols: msp_code_start, msp_code_end. Then
one can ask the lib to load the plugin. The lib would load it using libdl,
look for the two symbols, and then load the code as I'm currently doing
in test_msp.c. But I'd rather see it as a functionnality, not the only way
to load code (i.e. keep vice_msp_load_code, and add your load_msp_code)

> In any case, what end-programmer should see is
> msp_code_t msp_code = load_msp_code(vice,"jpeg2000");
> vice_buffer_t inbuf = vice_alloc(vice,out_bufsize);
> /* put data into input buffer */
> vice_buffer_t outbuf = vice_alloc(vice,out_bufsize);
> vice_msp_set_buffers(msp_code,inbuf,outbuf);
> vice_run_msp(msp_code);

Well yes, something like that. The problem is the application will have to
know exactly what the MSP code does. What I mean is the MSP (and BSP) code
and the app will most likely need to be designed together to interact
correctly, so I think the best place for the MSP code to be is in the
app. Or as a 'plugin' distributed with the app.

Vivien.

On Mon, 11 Nov 2002 ilya@theIlya.com wrote:

> Technically, we may create two layers. One is layer of direct VICE
> interaction, which we ourselves will use. i.e. code thatn does mean
> things like ioctls to /dev/vice. Another layer will be usable by
> end-programmers to write apps, using functionality provided by us,
> such as various devoding/encoding algorithms.

Right, that's how I saw it. And the upper layer would be based on, or
emulate existing libraries if possible, like libmpeg2.

> I would like to correct you. msp code is specific to algorithm, not app.
> Besides, there is one important problem: very limited number of people will
> have access to enough information to write plugins for libvice in any 
> foreseeable future.

That's right. But my concern is on efficiency: I think we need to have the
VICE do all the job if possible, i.e. fetch its data in mem, process it
with MSP, send it to BSP, write it back to mem, without doing anything
with the CPU except feeding frames one after the other. Thus I think a
'codec' (including things like libmpeg2 in this term) would be
nearly exclusively MSP/BSP code. So my point is, there won't be anything
common or generic to share between all those codecs, thus I don't really
see the advantage of putting all in a common lib. The lib should be
restricted to the common part, i.e. being able to load and execute our
code, provide and retreive buffers, and be signaled when job's done. Now,
whether those codecs take the form of a plugin that libvice can load, or
application code, is not really important.

> OK, approximately same thing as I was thinking about... However, best way to
> do all this, would be to mmap code using 64K pages, and then kick off DMA...
> or, when that is not possible, loading code into DMA buffer dirrectly will \
> be faster, I think.

Do we need speed for this? I think we don't care, code will (hopefully) be
put in iRAM during initialization and stay there (unless we want to bother
with on-the-fly code loading, something that could be nice, not a
priority I think, but then I agree with you).

> Why would VICE code and app need to interact dirrectly? There are very few
> cases I can imagine, and even those can be handled by callbacks.

Ok, maybe 'app' was not a good and accurate term. I was speaking of a
codec (which can be an app or a lib).
So, to sum it up, my vision of the whole thing would be something like
that:

		hardware
		kernel
		libvice (as it is currently mainly)
	libmpeg2_vice	libmpg123_vice ... (full of MSP/BSP code)
( here we provide an API compatible with respectively libmpeg2,
libmpg123 for example)
	 mpeg2dec	  mpg123		

> To make good API we will need protect end programmer from HW.

Indeed.

> Think about XWindows.

I don't know much about it unfortunately. Anyway, we're not doing a
full multimedia API, (we're not going to implement mpeg2 decoding for
people who don't have VICE for example ;)), so I'd rather keep things
simple and try to provide a 'VICE implementation' for a few common libs.
What do you think?

Or maybe if we want to use things 'a la XWindow' for multimedia, we should
take a quick look at gstreamer (unfortunately, there's no such thing as a
common multimedia API for linux, such as XWindow for graphics, or such as
DirectShow filters).

Vivien.