[sldev] Wind Sound CPU usage.

Callum Lerwick seg at haxxed.com
Mon Mar 3 01:33:36 PST 2008


On Mon, 2008-03-03 at 02:11 -0500, Jason Giglio wrote:
> 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.

Well, I would expect to share the same code between the two, and AFAIK
that's what he's doing.

Hmmm, I haven't actually looked at the code in a while. Okay, in the
inner loop I see:

cos():      Really, really slow.
sqrt():     Slow.
division:   Slow.
ll_frand(): Slow.
double <-> float conversion: Meaningless on x87, but possibly slow on
SSE/x86-64/PPC
float -> int conversion, two for left and right: Slow.

So, it's pretty much every inner loop no-no in the book. There's quite a
few directions to go to optimize here:

This isn't rocket science. We probably don't need double precision. We
don't need cryptographically secure random number generation. ll_frand()
could be replaced with a low quality but much faster random number
generator. Or just pre-generate a small buffer and loop it.

I'm not quite up to DSP filter design yet, so I can't be much help
there, but I know I've seen filter designs without cos() and sqrt() in
them...

The final result is 16 bit integers. Converting the whole thing to fixed
point may or may not help, to avoid the float -> int conversion. But it
appears this isn't the worst of our worries after all...

It may be possible to get away with pre-generating a sample loop and
just change the playback pitch. Might need to pre-generate a few
different pitches and interpolate to sound acceptable...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080303/07b338a3/attachment.pgp


More information about the SLDev mailing list