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

Pau Arumí parumi at iua.upf.edu
Sat Nov 17 12:42:01 PST 2007


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
Pau





More information about the clam-devel mailing list