[Clam-devel] Fwd: Half way patches to get multirate flowcontrol

[David García Garzón]

Last week i tried a new PushFlowControl which solved some of the problems for 
the flow control. Mostly, the 'two-do's-needed-to-consume-the-input' stall, 
the 'control-sender-takes-it-all' efficiency problem and 
the 'source-and-sinks-are-not-properly-sized' sindrome.

As I was not so convinced with the results, So instead of committing them i 
did a patch (attached) and reverted the changes. At least it served to better 
locate the problem.

The main changes were to do a 'recursive push flowcontrol with retry' 
according this algorithm (sorry for the pythonic):

for each source in network.inportLessProcessings() :
	ProcessElement(source)

def processElement(processing):
	while processing.canConsumeAndProduce() :
		retry = processing.Do()
		for each outport in procesing.OutPorts() :
			for each reader in outport.conectedProcessings() :
				processElement(reader)
		if not retry : return;

The main changes in the behavior are two: Former, now we retry each processing 
execution. Later, to avoid processings always able to be executed I used the 
Do return value for processing always able to execute (such as 
InputControlSender, Sources and Sinks) to say don't retry me. Not a nice way 
as that return value has had a lot of meanings along the clam history but it 
was valid for the experiment.

The Sources and Sinks behavior looked so different animals that i wanted to 
change the way they worked to be more like the rest of elements.

On the current implementation the Consume/Produce action was done in a special 
Do function called outside the network, on the Backend. The normal Do called 
within the network did nothing and did not modify the network status.

What i did was adding Sources/Sink a buffer pointer and a item count. The 
Backend just sets those pointer (which may warn about missing frames to write 
or read) and then the Network does all while the sources provide tokens. When 
they are exhausted they return false to the former algorithm.

By doing this i just had problem with awkward cases such as sometimes 
receiving buffer sizes which are not multiple of the clam buffer size (512). 
As commented recently this can happen when the backend buffer is smaller or 
when a backend (if found this with PortAudio over alsa/oss) just gives you a 
different buffer size than the intended one.

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
(Home) vokimon at telefonica adot net
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multirate.patch
Type: text/x-diff
Size: 10132 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070226/d7fe8053/attachment-0002.patch>