Delphi Graphics and Game Programming Exposed! with DirectX For versions 5.0-7.0:Sound and Music                       Search Tips   Advanced Search        Title Author Publisher ISBN    Please Select ----------- Artificial Intel Business & Mgmt Components Content Mgmt Certification Databases Enterprise Mgmt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Productivity Apps Programming Langs Security Soft Engineering UI Web Services Webmaster Y2K ----------- New Arrivals









Delphi Graphics and Game Programming Exposed with DirectX 7.0

by John Ayres

Wordware Publishing, Inc.

ISBN: 1556226373   Pub Date: 12/01/99














Search this book:
 



Previous Table of Contents Next Sound Buffers As stated above, the majority of time spent when programming DirectSound is in creation and manipulation of secondary sound buffers. The primary sound buffer can also be accessed, allowing the developer to change the primary sound buffer format or even implement custom mixing algorithms. There are a number of attributes and concepts associated with sound buffers that must be explained and understood before they can be put to good use. Audio Format As of this writing, all sound buffers must contain sound data in the pulse code modulation (PCM) format. pulse code modulation (PCM): An uncompressed audio format; the most common format for Windows WAV files. Fortunately, this is the most common format for Windows WAV files. Unfortunately, you cannot assume that any file with the .wav extension is in the PCM format. WAV files are also stored in the Resource Interchange File Format (RIFF), which is a complex, variable length file format consisting of header “chunks” followed by data “chunks” of variable length. Resource Interchange File Format (RIFF): A complex, variable length file consisting of variable length “chunks.” Each chunk can describe data or a header (which contains a description of the data following it). Commonly used for multimedia file formats, such as WAV files. The data chunks in WAV files can contain audio data in any number of different formats (you can examine this by opening the Sound Recorder under Accessories and choosing Save As). WAV RIFF files contain a header “chunk” in the form of a TWaveFormatEx structure, which allows the developer to check the format of the WAV file before copying its data into a secondary sound buffer. The TWaveFormatEx structure contains a number of useful pieces of information describing the WAV file, such as the number of channels, the sampling rate, and the number of bits per sample. The TWaveFormatEx structure is defined as: TWaveFormatEx = packed record wFormatTag: Word; // format type, must be WAVE_FORMAT_PCM for DirectSound compatibility nChannels: Word; // number of channels (1 = mono, 2 = stereo)} nSamplesPerSec: DWORD; // the sample rate, in hertz (samples per second), typically 11025 (telephone quality), 22050 (radio quality), or 44100 (CD quality) nAvgBytesPerSec: DWORD; // average transfer rate (nSamplesPerSec*nBlockAlign) nBlockAlign: Word; // bytes per sample (nChannels*nBitsPerSample/8) wBitsPerSample: Word; // number of bits per sample (8 or 16) cbSize: Word; // number of bytes of extra information, can be ignored end; hertz (Hz): A measurement of samples per second. The audio format of secondary buffers will be dictated by the format of the WAV file they contain. However, the primary buffer has a default audio format of 22,050 Hz, 2 channels, 8 bits per sample. DirectSound gives the developer the abilities to change this format, as we’ll see shortly. Buffer Memory Locations When DirectSound creates a secondary sound buffer, it automatically tries to locate the buffer in RAM on the sound card, if available. If there are no hardware buffers available, the sound is stored in system memory. Sound buffers located in hardware have the shortest path to the primary sound buffer, and thus are appropriately suited for sounds that are needed quickly and will be repeated often (such as gunshots), or looped continually (such as an engine hum). Although sound buffers are created in hardware memory by default, the developer can specify the desired memory location of a sound buffer by using specific flags, as described later in this chapter. The number of sound buffers that DirectSound can make are restricted only by available free memory (system memory and sound card hardware memory) The existence of hardware buffers usually indicates the existence of a hardware mixer. Each hardware buffer takes up one hardware mixing channel (even if the buffer isn’t playing), and the number of available hardware buffers is limited by the number of hardware mixing channels. This affects the number of sounds that can be mixed by the hardware mixer. DirectSound will take up the slack by performing any necessary mixing in the software mixer. This will all be transparent to the developer but is useful knowledge when optimizing performance. Buffer Types Secondary sound buffers come in two flavors: static and streaming. Static buffers are used for short sounds that can be placed into memory in their entirety. These are typically short, often repeated or looping sounds. Streaming buffers are used for large sounds that cannot fit into a reasonably sized block of memory, or for sounds that change often and must by copied into the buffer in pieces as it is playing. By default, DirectSound tries to create a streaming buffer. However, like the buffer memory location, the developer can indicate a desired buffer type through the use of various flags in the buffer creation function. Optimum Buffer Configuration Since DirectSound tries to locate secondary sound buffers in hardware memory first, sound buffers should be created in order of importance. This will ensure that the sounds used most often will enjoy the greatest performance. However, to optimize performance, the developer should dictate the type of buffer when one is created, and where it will be placed. In general, static buffers should be used for short, often repeated or looping sounds, and should be placed in hardware memory. Streaming buffers, on the other hand, should be placed in system memory (on ISA cards you have no choice, as hardware streaming buffers are not supported). Locating a streaming buffer in hardware does not eliminate any processing overhead as new audio data is continually moving between hardware and software. Thus, hardware buffers should be reserved only for buffers that are not continually updated. The exception to this rule is when a sound buffer will be duplicated. DirectSound allows copies of a sound buffer to be created that contain their own play and write pointers but do not copy the actual buffer memory. This is useful when a certain sound will be played multiple times, but you want the user to hear the end of the previous sound while the beginning of the next sound is being played (i.e., the dissipation at the end of a laser burst while the next laser burst is charging). Duplicating a hardware buffer requires using hardware resources that may be needed elsewhere. Indeed, the call to duplicate a hardware buffer will fail if there are an insufficient number of hardware resources available. For this reason, it is better to place static buffers that will be duplicated in system memory. An example of duplicating a sound buffer for this purpose will be demonstrated later in the chapter. Previous Table of Contents Next Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.