Peiman
>
>

2009/5/20 Mike Moser-Booth <mmoserbooth@gmail.com>
>

> Hello,
>
>
>
> I think the CPU spike has something to do with the fact that Intel processors actually have to strain harder when dealing with very small values than with large ones. As for the elapsed time, I never really paid attention to it, but I always just assumed the "s" stood for seconds. But I couldn't finish a cup of coffee in 133 seconds! So maybe I'm wrong on that.
>
>
>
>
> .mmb

>
>
>
> peiman khosravi wrote:
>
>

> Dear all,
>
>
>
> I am using csound double to render to disk a very complex CSD that uses PVS opcodes (including the highly CPU intensive pvsblur) with FFTsize=2048, overlap size of FFT/16 or less (e.g. 128), window-size of FFT*8, ksmps=1 and 96khz sr, also using flag -3 (for 24 bit sample output). These settings would naturally be impossible to run in real-time considering the nature of my csd.
>
>
> So I am not surprised that at the end of the non-real-time performance the terminal prints out this:
>
>
>
> Elapsed time at end of performance: real: 135.728s, CPU: 133.630s
>
> Is this just theoretical? How can the CPU go over 100% without csound freezing? I admit I don't understand what this means exactly. In short is this a problem or can it cause problems? (apart from the computer fan spinning like crazy and me having to finish a cup of coffee for each render!).
>
>
>
>
> Also would it make sense that for some reason audio signal of 0 sample value seems to create some sort of CPU spike in real-time performance?
>
> Many Thanks
>
> Peiman
>
>

>
>
>
>
>
>

> Send bugs reports to this list.
>
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>