Sound/Game system status and work. Was: Re: [Bf-committers] 2.36 status...

Alexander Ewering blender at
Wed Jan 5 04:38:37 CET 2005

On Tue, 4 Jan 2005, Jacques Beaurain wrote:

> Hi,
> Just returned from holiday and will soon be ready to start working on some of 
> the audio stuff as described below ...Except  I see someone (Alexander) 
> already beat me to it and started. I still believe I can be of some help. 
> Will first need to catch up with everything that I missed while away though.

Hi Jacques,

I think this is a good point to give a complete overview of the work I've done
so far.

I had a last showstopper bug, which got fixed just yesterday, and the
redesigned sound system now appears pretty solid.

I come from a sound-engineering background as well (see ;), so I hope I'm half-competent
for this stuff :)

So, here we go:

- Removed dependancy on OpenAL. Mixing itself (having several channels
   available for sound playback) is now done using SDL_mixer, and
   sound output is done via SDL

- 3D sound is calculated on the fly by my own code. It does basic
   left/right panning based on angle to the viewer, AND also creates
   a pretty convincing "behind" experience on standard stereo speakers
   by 1) inverting the phase of the sound on *one* of the two stereo
   channels after panning   and  2) applying a slight low-pass filter
   (bilinear filter) to it. I don't even know if OpenAL did this.

- I did *not* implement Doppler shift. Is this really necessary? I'm
   not even sure it worked in the previous engine, so...

- Pitch of sounds can also be set as usual (where as usual means: did it
   even work before? Like so many things...).

   Pitch shifting is done on the fly before the sample is passed to SDL_mixer,
   on the complete sample. So for very very long samples, it might give a
   slight delay because of the processing time... though on a Athlon XP 2100+,
   it took 1.5 seconds to resample a 40 MB WAV, so I guess that's OK :)

   This also means, of course, that the pitch of a sound can't be changed
   anymore while it is running.

   Pitch shifting is done using very simple linear scaling of the sample, and
   applying a bilinear filter afterwards. Sounds horrible for some sounds, so
   this might be a place where someone could introduce a better resampling
   algorithm :)

- Finished the implementation of the "Listener" by moving it to the Scene and
   thus enabling saving and loading of its settings (this did never work before)

   "Gain" setting from Listener is used as a "Master gain" to the overall mix

- Sound *attenuation* with distance is done using inverse quadratic attenuation,
   actually exactly the same code as for Quad lamps.

   A sound now has the following parameters:

   - Vol: Sets the basic gain applied to the sound (for adjusting levels between
     different sounds

   - Pitch: The pitch in semitones (+/- 24)

   - Loop: Sets looping on/off. Only forward loops over the whole sample are
     supported now (like previous engine)

   - 3D: Toggle 3D evaluation of the sound relative to the listener. Additional
     parameters then are (different from previous engine):

     - Dist: Sets the half-energy distance (like for quad lamps)
     - PanFac: Sets the pan width, determines how far this sound can pan
       left/right in the sound field. This may be useful to set to smaller
       values than 1.0 (100%), for example, if you want very 'big' sounds
       with a non-specific location, or use stereo samples, which are also
       panned by default, and you don't want this.

- Overall latency is very good. For the few cases when I actually managed to get
   sound from the old sound system (which was VERY rarely), it appeared with
   anywhere between 0.3 and 2 seconds latency.

   With a buffer size of 512 samples, I still get very few, if any, dropouts, and
   a latency of about 11 ms.

   Latency is *very* important for the realism of a sound scene.

- Native support for both raw PCM WAV files (mono/stereo, 8/16 bit) and Ogg
   Vorbis (via SDL_mixer). Ogg Vorbis files are not decoded on the fly, but on
   load. So even if it reduces file size of an exported runtime or a blend file,
   it will still use as much memory as if it were a WAV. (Actually, probably
   twice as much in most cases, because it's converted to mixing format (stereo))
   by SDL_mixer after loading. But with 512 MB of memory in most machines nowadays...

- It is very hard to get Sequencer Audio and Game engine audio to work
   together without conflicts. This is because Seq uses raw SDL (needs to do this
   for A/V sync), and the Engine uses SDL_mixer. Also, the engine expects
   the sound for it to be *always* initialized (for example, if you press "Play
   Sample" in the sound buttons), but so does the sequencer (for ALT-A, etc).

   So for now, BOTH systems have an on/off toggle. The Game engine has the old
   toggle in the userprefs, the Sequencer has a new toggle in the Sequence window.

   If you work on a Game/Realtime engine project, you won't ever use sequence audio,
   so that's fine, I guess.

- I've stress tested this with a current project I'm working on which has about 30
   sound actuators which randomly trigger and popup all around the listener, and
   didn't come across any problems anymore.

- I couldn't manage to get this all inside #ifdefs, because it's just too much that

Phewwwwww... Such a long text! Now, what I would still think is necessary:

- A better resampling algorithm (fast enough, but better quality than this)

- Integration of SDL, SDL_mixer and vorbisfile into extern/ so that there are
   no strange incompatibilities.

   Also, SDL etc. should be written into runtimes.

| alexander ewering              instinctive mediaworks
| ae[@]instinctive[.]de   http://www[.]instinctive[.]de

More information about the Bf-committers mailing list