[Clam-devel] Re. Some explanations about the last low-latency feature

[globot]

>I've just finished and tested the last feature (low-latency ladspas, or
>"Processings can configure themselves with the backend buffersize"), and
>the trunk is stable again (r10958).
>
>Some explanation about the changes:
>
>Time domain processing such as ladspas should have its port sizes
>configured with the backend buffer size. Why? to achieve the best
>latency.
>In other words, imagine a network consisting on a pipeline of ladspas.
>We'd want this kind of activation sequence:
>- start jack callback
>-- audio source execution
>-- ladspas executions
>-- audio sink execution  (getting the output from the last ladspa)
>- end jack callback. (with the input processed)
>
>There where two main problems to implement this:
>
>        1. The NetworkPlayer initialized the backend (i.e. jack) at
>        start time.  So, after the processings where configured.
>        
>        2. Processings (in its ConcreteConfigure) should be able to
>        decide wheter to use the backend buffersize. But the processings
>        don't know it's network (because they can also be used
>        independenly)
>        
>1. Was quite simple to resolve addint a new (virtual) method Init() to
>NetworkPlayer that is called when a Player is setted to a Network.
>
>2. 
>A new unsigned BackendBufferSize() and unsigned BackendSampleRate()
>interface has been added to Processing base class. 
>Processings now have an optional back-link to its parent Network. If no
>network exists those methods defaults to sensible values (1024, 44100),
>if exists, the getter is delegated to the Network, which again delegates
>to the Player (again, if exists).
>Then I faced a related problem: processings can get configured before
>being added to the network. Specifically, some processings get
>configured with its default constructor, and some others at xml loading
>tile.  Here I did a quick (and dirty?) solution. Reconfigure the
>processing in Network::AddProcessing(name, proc)
>
>Summing up, now Clam can be as low-latency as the backend allows. But
>we'll need to update the ConcreteConfigure of some processings. The ones
>which we want to be low-latency. By now I've only changed Sinks, Sources
>and LadspaWrapper.
>
>Enjoy
>  
>

It look like good news, I will try it probably tomorrow afternoon... It 
give me hope to reach a very low latency, (if i can reach less than 3ms 
for a complex network, i am back on track :) :) :) chayo chayo, or Bravo !!

this is a realy cool !