[sldev] Wind Sound CPU usage.

[Robin Cornelius]

On Mon, Mar 3, 2008 at 7:11 AM, Jason Giglio <gigstaggart at gmail.com> wrote:
> Callum Lerwick wrote:
>  > I've only profiled with my OpenAL patch which doesn't yet have noise
>  > generation. (still haven't got around to looking at what Robin has done,
>  > have kinda ended up trying to tie up loose ends with OpenJPEG...)
>
>  Robin's patch looks a whole lot like the old code, I suspect it won't
>  profile much better, but I guess we can't tell for sure until we try it.
>
>  If the OpenAL version of wind doesn't profile any better I think we need
>  to ask some hard questions about the necessity of this "feature".
>


Yea, my implementation on the back of openal is subtly different though to fmod.

How it (they) work is as follows

There is a function that receives a pointer to a buffer, some velocity
information etc and this generates a whole lot of random white noise
and applys some FIR filters to give resonance at a given frequency and
a pinking filter. The function has one loop just runs from 0 to
no_samples generating the random noise.

This is common to both fmod and my messing around. I have made no real
changes to the implementation of this bit (and i have just seem
callum's email as i was writing this reply) so yes there is room for
lots of optimization here, this is not something i have even
attempted.

Now this is where it differs

Fmod has a call back for *every* dsp unit so when ever sound is about
to be played a call back is generated from fmod and i would guess this
is fairly high priority, a pointer to fmods buffer is returned and the
windnoise mixed over what ever else is attempting to play. This occurs
at a high rate as basicly you need 44100 samples per second (two
channels L and R and done at the same time). the rate of the call back
is 44100/size_of_dsp_unit. I *believe this is a 20ms block (@44100Hz)


My implementation on top of Seg's openal queues buffers of wind noise
in openal's buffer queue system. On every frame i look to see if there
are any empty buffers and fill them back up.

Problems with my implementation is its a bit of a balance between
having enough buffers (or long enough buffers) to not run out of wind
if the frame rate is low and having a reasonable response time to
movement (when the wind needs to change).

FMOD does not have this latency issue as its callback based and there
is no way it seems to access openal's mix buffer.

I don't run my viewer with my wind patch nor distribute my debs with it either.

Robin