[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: aRts question
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2002-05-12 20:01:45
[Download RAW message or body]

   Hi!

On Tue, May 07, 2002 at 06:08:43PM +0200, Martin Vogt wrote:
> for video support I think aRts needs some kind
> of signal mechanism.
> 
> Example:
> 
> kwintv creates an arts image and gets the pointers
> to the destination over shared mem.
> Then it writes data to it and
> calls something like image->out()
> 
> and the image is passed through the filter
> graph (and to the display at the end)
> But what should kwintv do after image->out() ?
> 
> It needs to know, when the image is
> available again, and for performance reasons
> a poll is out of question.
> 
> Is there a way to signal the remote client
> a image_avail() or something like that?
> One option would be to put a semaphore into
> shm and let the client block after the 
> image->out().

I think the way to go is to use some standard MCOP mechanism for
communication, so that MCOP is the only thing that knows how the data
is transferred, and the application/modules need not care about this.

So the mechanism should be something like an asynchronous stream of something
(video image? byte? ...?), and the way notification works should be like for
any other stream of this kind: the sender initiates sending, by setting up
aRts to ask him for new data, and once aRts asks, he feeds an image. Once the
image has been successfully received and processed, the sender will get asked
for another image.

However, aRts doesn't know about shared mem right now. So it will use sockets
for transfer. You might argue this is too slow, so the options are either to
add a sharedmem transport to MCOP (which is the clean way to go) or use MCOP
in a different way to just do the signalling and implement the shared mem
thing by hand (which I would *not* recommend).

As for plain signalling, there are a variety of possibilities:

A. if you think of callbacks (as in plain C callback function pointers), the
straigtforward mapping of this to IDL is like

interface WorkNotify {
	oneway void workDone();
};

interface Worker {
	oneway void doWork(WorkNotify callback);
};

whereas the client implements the WorkNotify interface and call

	worker.doWork(self());

and self() is implemented like

    WorkNotify self() { return WorkNotify::_from_base(_copy()); }

and the worker implementation calls

	callback.workDone();

when done.

B. you can use attribute change notifications, for instance like

interface Worker {
	readonly attribute bool busy;
};

where the worker would do

	busy_changed(true);

and

	busy_changed(false);

which you can watch with the usual Arts::connect(worker,"busy",self(),"...");

C. finally you can use a stream where you transfer something, for instance
the offset inside the sharedmem segment and use the usual setPull() style
synchronization

interface Worker {
	async in long stream inaddrs;
};

to indicate that a packet has been released.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]