[Clam-devel] Fwd: Half way patches to get multirate flowcontrol
David García Garzón
dgarcia at iua.upf.edu
Mon Feb 26 09:11:18 PST 2007
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() :
while processing.canConsumeAndProduce() :
retry = processing.Do()
for each outport in procesing.OutPorts() :
for each reader in outport.conectedProcessings() :
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10132 bytes
Desc: not available
More information about the clam-devel