[sldev] Wind Sound CPU usage. (patch-4)

Aimee Walton aimee at ama-zing.co.uk
Thu Mar 6 05:16:30 PST 2008


Yeah, I'm sort of on the verge of stopping poking at it like this and  
throwing the whole lot out and starting again with something that  
just uses fixed point, I'm just short on time.

Filtering white noise probably isn't the most efficient way of  
generating pink, cos and sqrt need to hit the bin, the clipping has  
bugged me from the start and needs to die, along with all those  
32767s and 32768s, which are a false assumption anyway. If anything  
is to be done about clipping it should really just check for a  
threshold level in the mixed audio and then reduce the wind gain to  
prevent it, effectively ducking the wind noise with the other  
audio.The wind is going to be a much lower priority than whatever  
else it's being mixed with, it could even be disabled completely if  
everything else is much louder, rather than just adding unintentional  
dither to the music stream and wasting cycles.

Without actually checking, I think the filter's a 4th-order low-pass  
Chebyshev.

- Aimee.

On Mar 6, 2008, at 07:36, Callum Lerwick wrote:

> And we may be able find a faster filter design, actually the existing
> one appears pretty simple in the inner loop, but cos()/sqrt() are
> killers. Establishing a control rate might make this manageable.  
> But it
> is not documented what the filter actually *is*... Sounds like a
> bandpass filter. 24db/oct? I suppose I can fire up baudline and see...


> The final clip check irks me. If you're clipping, you've failed  
> anyway.
> The generator needs to be bounded to not clip anyway. Nuke  
> clipSample(),
> which will make any clipping even more noticeable (integer  
> wraparound),
> and tweak the scaling factor down (the 32768.f) until it stops  
> clipping.
> That will save us some branches.
>
> The conversion code I wrote for something else is using 32767, one  
> less,
> but then the float is pre-clipped to -1/+1. Since this is a resonant
> filter we're dealing with, its possible for the output samples to  
> exceed
> the range of the input samples, so it may need to be tweaked down a  
> bit
> more...


More information about the SLDev mailing list