Hi Hans, The thread in question here would be invoked when a "set" message is sent to the object. In this case, I need to load the Impulse Response from the disk and optionally do a test convolution and normalize it. I'm assuming (yeah, I should just check ;-) if I block on an inlet, I'm blocking the whole audio thread?
Convolution with an increasing block size naturally involves different work-loads on different sample blocks (some sample blocks finish a large block that can then be processed, some don't). If the scheduler is picky/precise enough (AudioUnits is), you can't get away with this "ragged work load". Its not a matter of decreasing CPU usage - of course scheduling things to run in a worker thread increases CPU usage a little - its a matter of keeping the _perform call CPU cycles consistent. -Seth On Wed, Apr 6, 2011 at 11:26 AM, Hans-Christoph Steiner <[email protected]> wrote: > > On Apr 4, 2011, at 10:48 PM, Seth Nickell wrote: > >>>> 2) Anyone have requests for features/api? Its currently simplistic: >>>> - takes a "read FILENAME" message, loads the file, does a test >>>> convolution against pink noise to normalize the gain to something sane >>> >>> Is this done within the main Pd audio thread? >> >> The convolution engine has support for doing it either on the calling >> thread, or a background thread. I'm thinking of default to a >> background thread. That seem like the right move? > > 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. > > .hc > > >>>> - caches the last N impulse responses, as the test convolution >>>> takes a little time >>>> - allows setting the cache size with a "cachesize N" message >>> >>> To make sure I understood this: cachesize is not the size of the first >>> partition of the partitioned convolution, but the cache that tries to >>> avoid >>> audio dropouts when performing the test convolution? >> >> The convolution engine can swap-in a pre-loaded ('cached') IR in >> realtime without glitching... but it means keeping 2x the Impulse >> Response data in RAM. To keep the default API simple but useful, I'm >> defaulting to caching only the last 5 impulse responses in RAM. >> "cachesize N" lets you increase that number.... lets say in a >> performance you wanted to use 30 different impulse responses and you >> have 2GB of ram... should be nbd. >> >>>> >>>> - disable normalization with "normalize 0" or "normalize 1" >>> >>> Yes, disabling this could be a good idea! You could also add a "gain 0-1" >>> message for manual control. >> >> Its worth noting that impulse responses are usually whack without gain >> normalization.... like factors of hundreds to millions off a usable >> signal. >> >>>> Features I'm considering (let me know if they sound useful): >>>> - load from an array instead of from disk (no gain normalization?) >>> >>> Very good. >>>> >>>> - It wouldn't be hard to enable MxN convolution if that floats >>>> somebody's boat. >>> >>> I am sure if you come up with a convolution as efficient and flexible as >>> jconv by Fons within Pd, then soon a multichannel use and hence request >>> will >>> come up fast. >> >> I'd be interested in what flexibility means in this context, it might >> give me some good ideas for features to add. Efficiency-wise, last >> time I benchmarked its more efficient than jconv, but the difference >> is offset by less graceful degradation under CPU load (I convolve in >> background threads to preserve realtime in the main thread while >> avoiding an irritating patent that's going to expire soon...). >> >> WRT to Pd's audio scheduling... are Pd signal externals held to >> realtime or can my dsp call vary the number of cycles it takes by 100% >> from call to call? VST seems to do ok with this, but AudioUnits get >> scheduled to run at the very last instant they possibly could. If Pd >> can have some variance, I can drop the threads and improve the >> external's degradation under high CPU load. >> >> thanks for the feedback (also, is the best list for this kind of >> feedback?), >> >> -Seth >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > ---------------------------------------------------------------------------- > > As we enjoy great advantages from inventions of others, we should be glad of > an opportunity to serve others by any invention of ours; and this we should > do freely and generously. - Benjamin Franklin > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
