Dear Perry,

Thanks very much for the response and for testing the program performance.  I am certainly running much much more than the convolution process.  I'm not advancing time every sample but I am sending and receiving Events at a fundamental frequency (every 6 - 15 kHz depending on the configuration) however, I would not expect this to take over the system performance.  I mentioned previously that running my program without the convolution function took the JACK DSP Load from about 2.5% to about 3.5%.

After further tests I've found that the sample size, the equivalent to "CelloBodyShort.wav", has very big impacts on the performance.  A sample size of 8KB or about 160ms raises the JACK DSP Load to about 30%.  A sample size of between 16KB or about 320ms raises the JACK DSP Load to over 60%.  And finally a sample size above 16KB pushes the DSP Load to 100% with lots of Xruns.  Is this consistent with your measurements?

I am now running the convolution process and my CPU usage is around 8.5% with the JACK DSP Load running at about 35%.  So it appears that my problem is more around the performance of JACK.  I'll keep testing.  I'd like to run much longer samples than 320ms.

Regards,
Mitch

> From: prc@CS.Princeton.EDU
> Date: Wed, 23 Sep 2015 14:15:13 -0700
> To: chuck-users@lists.cs.princeton.edu
> Subject: Re: [chuck-users] FFT Convolution and CPU Load
>
> Hum….
>
> Just checked my example and my CPU went from 7% to 11% when I kicked on
> the FFTConvolve.ck program you cite. We can’t see all your code, so not sure what’s
> going on. Are you updating really often, like advancing time every sample or
> something?
>
> PRC
>
>
>
> > On Sep 22, 2015, at 9:00 AM, chuck-users-request@lists.cs.princeton.edu wrote:
> >
> > // FFT convolution with static impulse response
> > // by Perry R. Cook, November 2014
> > // upsides: as efficient as it could be, save for
> > // constructing a specific fft convolution chugin
> > // downsides: minimum delay is length of impulse response + buffers
> > // fix: break into pieces and overlap add
> > // Other fix: see filter version using my FIR Filter chugin
> >
> > // our fixed convolution kernal (impulse response)
> > SndBuf s => FFT ffth => blackhole;
> > "CelloBodyShort.wav" => s.read; // whatever you like (caution of length!!)
> > 2 => int fftSize;
> > while (fftSize < s.samples())
> > 2 *=> fftSize; // next highest power of two
> > fftSize => int windowSize; // this is windowsize, only apply to signal blocks
> > windowSize/2 => int hopSize; // this can any whole fraction of windowsize
> > 2 *=> fftSize; // zero pad by 2x factor (for convolve)
> > // our input signal, replace adc with anything you like
> > adc => Gain input => FFT fftx => blackhole; // input signal
> > IFFT outy => dac; // our output
> > fftSize => ffth.size => fftx.size => outy.size; // sizes
> > Windowing.hann(windowSize) => fftx.window;
> > // <<< s.samples(), fftSize >>>;
> > windowSize::samp => now; // load impulse response into h
> > ffth.upchuck() @=> UAnaBlob H; // spectrum of fixed impulse response
> > s =< ffth =< blackhole; // don't need impulse resp signal anymore
> >
> > complex Z[fftSize/2];
> > 1000 => input.gain; // fiddle with this how you like/need
> >
> > while (true) {
> > fftx.upchuck() @=> UAnaBlob X; // spectrum of input signal
> >
> > // multiply spectra bin by bin (complex for free!):
> > for(0 => int i; i < fftSize/2; i++ ) {
> > fftx.cval(i) * H.cval(i) => Z[i];
> > }
> > outy.transform( Z ); // take ifft
> > hopSize :: samp => now; // and do it all again
> > }
>
> _______________________________________________
> chuck-users mailing list
> chuck-users@lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users