[PD] Making a Realtime Convolution External

[Hans-Christoph Steiner]

On Apr 6, 2011, at 2:52 PM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-04-06 20:26, Hans-Christoph Steiner wrote:
>>
>> Pd has its own scheduling system which is best to stick to as long as
>> you can so that you can keep the deterministic operation intact.  For
>> convolution, I can't see a reason to use a thread.  It adds  
>> complexity
>> and more code to run, but if the CPU is overtaxed by realtime
>> convolution processing, you are going to get an interruption in the
>> audio regardless of whether the processing is in a thread or not.
>>
>
> partioned convolutions can gain massively from parallelisation.
> given that we have more and more CPUs available, i think it is a good
> thing to try and do a multicore convolution.
>
> otoh, if there is only a single thread doing the convolution, then  
> there
> is no parallelisation, and thus the only thing gained is complexity.
>
> using "threats" does not mean that things have to get non- 
> deterministic,
> and indeed a lot of software uses threads and stays completely
> deterministic.



Yes, you can make things deterministic using threads.  Coding without  
threads, its basically automatically deterministic, but when using  
threads, you have to code things right to have it deterministic.   
Having multiple threads to support multiple cores definitely makes  
sense, so I guess this multi-threaded pd object would just need to  
wait for the results of all threads before letting the DSP tick  
complete, thereby ensuring deterministic behavior.

.hc


----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom