[Clam-devel] subnetworks interfacing - NE several opened files

[Pau Arumí]

On dj, 2008-07-24 at 16:53 +0200, David García Garzón wrote:
> El Thursday 24 July 2008 16:33:49 Karsten Krispin va escriure:
> > Am Donnerstag, 24. Juli 2008 10:51:37 schrieb Pau Arumí:
> > >         Network subnet;
> > >         subnet.AddProcessing(..);
> > >         ...
> > >         Network net;
> > >         net.AddNetwork( subnet );
> > >
> > >         Or maybe we should generalize Processing/Network -> Module? so
> > >         net.AddModule
> >
> > Sorry for jumping in...

Nice you jumed in...

> >
> > It might be tough approache, but what about considering a Network to be a
> > Processing?
> >
> > If a network tells a Subnetwork to process it's childs, simply the Do() of
> > the Subnetwork gets called and in turn calls it's internal flow control.
> >
> > That way you don't have to bother about childs' scheduling through serveral
> > levels of the hierarchy.
> >
> 
> That's a good point, and that would be a solution easier to reach, closer to 
> current ProcessingComposites. But i think that splitting the flow control 
> does not provide as many scalability enhancements as for the user interface. 
> Indeed i guess you may end up having higher latencies. Pau, who is developing 
> a new schedule algorithm for his thesis could confirm that or not, but i see 
> it like considering an irregular tetris piece set as a rectangular box in 
> order to fit several of them in the minimal space.
> 
> Is that the point, Pau? (a new chapter for your thesis on scability?)


In terms of composition structure, yes, both leafs and a composites (processing 
and network) should be treated uniformly as components. 

But in terms of running it have its problems.
The tetris metaphor is a good one: we want the flow control to generate iterative
schedulings (that is processing execution lists) divided in callback activations.
The callback activation is defined by the input and output ports connected to the 
backend driver (Jack, Portaudio, Ladspa,...)
Therefore, forcing subnetwork to also run in complete "callback 
activations" is too restrictive, and could lead to non optimal latencies in the 
upper callback --what the user sees or hears.

Also, we'd like to have networks whose ports do not have all the same execution rate 
(imagine a subnetwork that performs 44kHz->22kHz rate conversion, with the same port size). 
While it is impossible to say what is an individual Do of this network (or a callback
activation), seeing the flattened network all makes sense (or the network have rate 
mismatches and can not be executed anyway)

BTW David, the new callback-based static scheduling is ready (and tested) but implemented in 
python. I'll work on a proper integration after the summer.


P

> David.
> 
> 
> 
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel