Avoiding a DirectSound3D Disaster

 Using the DirectSound 3D API

DirectSound 3D
Page 1
   Page 2

While there are a number of sources for information about using the DirectSound3D API, it's equally important to know how not to use it. At last year's Computer Game Developers' Conference, a number of programmers working on 3D positional audio for games explained problems that they had encountered and the lessons that they had learned during development. Their problems resulted in poor performance in their games and little or no apparent 3D effect, even on the sounds the developers most wanted to position in 3D space. I've boiled their comments down to four rules that you should follow when implementing 3D positional audio in your own title.

1. Never Use Variable Frequency Buffers Unless They're Actually Required. It's important not to request variable frequency sound buffers when they're not necessary. This is a common mistake because it's the default in some of the DirectSound SDK examples. To make best use of a hardware DirectSound accelerator, pay attention to the flags specified in the lpcDSBufferDesc.dwFlags parameter, which are passed to IDirectSound::CreateSoundBuffer(). Some of these flags are straightforward - for example, DSBCAPS_LOCHARDWARE asks for a hardware-accelerated buffer and DSBCAPS_CTRL3D asks for DirectSound3D control. Other flags have implications for hardware accelerators that aren't so straightforward. The worst offender is DSBCAPS_CTRLFREQUENCY, which specifies that you need to be able to adjust the buffer's playback frequency after the buffer has been allocated. There are circumstances where this is a useful capability (some racing games use it to adjust the pitch of an engine, for example), but most of the time it's not required.

You also need to be aware that Microsoft's default lpcDSBufferDesc.dwFlags value, DSBCAPS_CTRLDEFAULT, includes the DSBCAPS_CTRLFREQUENCY flag (in addition to DSBCAPS_CTRLVOLUME and DSBCAPS_CTRLPAN), so you're not safe from this potential performance-draining trap if you supply Microsoft's default flag value.

Every buffer that is created with DSBCAPS_CTRLFREQUENCY (that is, set for variable frequency) will assign a sample rate conversion application to the audio stream. This consumes additional processing resources either on the host processor or on the audio hardware accelerator. If the host PC contains a multitasking audio hardware accelerator with dynamic resource management, the resources consumed by these sample rate conversion applications could have been used to accelerate more 3D audio channels. As you can see, blindly creating all streams as variable frequency streams will slow down the host processor and/or prevent 3D audio streams from being accelerated.

2. Never Use 3D When 2D Will Suffice. Only create 3D sound buffers when necessary. Many games have created all of their audio streams as 3D streams, but this practice results in a poor listening experience. An accelerated system will quickly run out of resources, and the result will be a complete lack of accelerated 3D audio. After all the hardware accelerator resources are consumed, the host will apply its 3D audio algorithm to the remaining streams. These streams will consume much more processing power than 2D streams, and further burden the system. The bottom line is that it's very wasteful to play every stream as 3D when it isn't necessary.

3. Avoid Using the DuplicateSoundBuffer Call. A common mistake that game developers make is not checking for the failure of a DuplicateSoundBuffer call. Failure to check for a bad return code from this call can lead to audio streams or sound effects being completely lost. The reason an application developer would use the DuplicateSoundBuffer call instead of using CreateSoundBuffer is strictly a matter of convenience. Instead of providing all the necessary parameters for each 3D buffer, you can just reference, or duplicate the parameters of a previously created buffer. This practice is acceptable only if you understand what happens when a call fails and can take corrective action.

Here's the problem: If a new 3D sound buffer is created using CreateSoundBuffer, the buffer will be created on the hardware accelerator if there is a free 3D channel. If no hardware 3D channels are available, the software 3D emulation in DirectSound 5 will automatically take over. However, if the new 3D sound buffer is created using DuplicateSoundBuffer, the host emulation in DirectSound 5 cannot take over. This is because DirectSound 5 doesn't have access to the parameters that you're requesting to duplicate. These parameters only reside in the hardware accelerator. Therefore, the DuplicateSoundBuffer will fail, and DirectSound 5 won't play the buffer on the host. At this point, the buffer is lost and the sound will never be heard. This isn't a problem if the game or application checks for the failure and then reinitiates the call using CreateSoundBuffer instead. However, the best approach is not to use the DuplicateSoundBuffer call. Only use CreateSoundBuffer, and this problem can be avoided.

4. Always Create the Most Important 3D Sounds First. To maximize the 3D impact on the listener, it's important to create the most important sound buffers first. Each time a 3D sound buffer is created using CreateSoundBuffer, the buffer will be created on the 3D audio hardware accelerator - if one is present in the system and has a 3D channel available. If all the hardware accelerated channels are already consumed, or there was no accelerator in the system, the host 3D algorithm in DirectSound 5 takes over and processes the stream on the host. This process is invisible to the game or application. The steams that are relegated to the host won't be positioned very well and will use more host processing power than 2D streams.

Follow the Rules

Always create the most critical 3D sound buffers first. That way, if there is an accelerator in the system, it will be used for the sounds that will have the most impact on the listener. It's no secret that 3D audio can be an immersive experience for game players. However, if you're going to adopt this technology, make sure that you avoid the common pitfalls associated with DirectSound3D. When followed, these four rules will maximize the impact of your audio and reduce unintended audio processing.

Rich Warwick's experience in the PC industry spans chip, gate array, and board level hardware design, as well as DSP software development. Rich joined Crystal Semiconductor Corporation in 1995 as a software development manager. He was responsible for the software development for Crystal's CS4610 PCI audio accelerator. He is currently the Manager of DSP Software Technology, leading the development of software for Cirrus Logic's "Sound Fusion" line of PCI audio accelerators.