On Wed, 27 Dec 2006, Tim Blechmann wrote:
from the user point of view, i think, it's a good idea, to have a specific separation between dsp and messaging, because both work with very different concepts.
But of the difference between dsp and messaging, which ones of the very differences of the very different concepts need to be emphasized, and which ones need to be downplayed? Just because there are differences, doesn't mean they need to be outlined in bold or tilde.
Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality?
well, computing audio signals is usually way more expensive then computing messaging. for my personal performance patch, the messaging is usually less than 2% of the cpu usage...
Ok, but messaging tends to happen in bursts. In a single-thread system, this has to happen between the processing of two blocks. If a [metro] gets only triggered every 100 blocks, that's 200% of CPU usage which ends up delaying the next block, so latency has to be increased in order to remove jitter.
If there was no DSP chain, or if the chain included all of the non-DSP, we might delay such determination until later... (but should we?)
if there was no dsp chain, it would be easier to utilize several audio threads (see jackdmp) ... caching would definitely be worse, though ...
But what if there was one dsp_chain per thread, and that when the dsp_add() phase happens, it adds to one of several dsp_chains depending on some kind of load-balancing metric?
The price an artist pays for doing what he wants is that he has to do it. -- William S. Burroughs
Damn right.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada