Designing Sound

Denormal and Drift Contingencies
In native code a problem arises with an accumulating phasor or long exponen-
tial decay envelope where floating point numbers eventually degenerate into

---

324
Game Audio
denormal form
. On many processors this leads to an immense performance hit
or a complete lockup of the program. Objects we have looked at so far in this
book are, on the whole, well written and perform for hours or days without
reaching a pathological state. But it is not always possible to code DSP with
both an efficient and safety critical approach, so some thought needs to be
given to long-term behaviour. Bearing in mind that some oscillators drift in
phase and accuracy, some effort should be given to avoiding designs that are
sensitive to this and to testing properly to make sure long-running ambient
keypoint actors don’t degenerate. Many players will leave a game running for
days, and VR software installations for world simulators must be expected to
run with up-times of months or optimistically years. The most obvious approach
is to reset objects on a periodic basis. But unless this method is built into the
object, the only choice is to delete and reinstantiate running code. In a large
DSP graph this can be a headache if it means the whole graph must be rebuilt,
and it could cause unexpected clicks or dropouts. A scheme that works well
is to give all objects a finite but large lifetime after which they will fade out
and self-destruct. In almost all reasonable scenarios a player does not expect to
hear a running sound for days on end. If a list of objects that
should
or
could
be active in a given space is kept then these objects can be reactivated when
there is player activity in the vicinity of them.