 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
The DirectSound subsystem of Windows CE consists of two basic components. The client component (DSOUND.DLL) that is loaded into the client application's process space, and the server (DSOUNDS.DLL) component that runs as a filesystem driver in the DEVICE.EXE process.
The client component allows the client application to interact with the DirectSound subsystem using the standard DirectSound interfaces published in the DSOUND.H header file. Since many processes may all want to use DirectSound resources, it is the server component that actually manages hardware and buffers. The client portion simply proxies client application requests to the server component, where buffers are mixed and the primary buffer output is rendered.
The DirectSound HAL drivers are simply DLLs that get loaded into DEVICE.EXE by the DirectSound server (DSOUNDS.DLL).
The following articles detail the structure of the DirectSound HAL driver model:
- DirectSound HAL Driver Structure
-
Primary and
Secondary Buffers
DirectSound HAL Driver Structure
The Windows CE DirectSound driver model is very similar to the one used in Windows 95/98. This will allow many drivers written for the desktop to be used with minimal changes.
DirectSound drivers support two classes of logical objects within the driver. These are referred to as the DsDriver object and the DsDriverBuffer object. These driver objects support the IDsDriverand IDsDriverBufferinterfaces accessed by DirectSound.
These two interfaces form the basic pattern of the driver. If you compare the definitions of the IDsDriverand IDsDriverBufferinterfaces to the IDirectSoundand IDirectSoundBufferinterfaces, you can see how they map directly to the DirectSound structure.
The Windows CE DirectSound HAL, unlike its Windows 95/98 counterpart, also supports capture through the IDsCaptureDriverand IDsCaptureDriverBufferinterfaces.
Primary and Secondary Buffers
In DirectSound, the term primary bufferis used to describe the buffer that receives the output of the software mixer. The term secondary bufferis used to denote all other buffers - whether they be mixed in hardware or provide input to the software mixer. A hardware secondary bufferdenotes a buffer that will be written directly to the hardware via the primary buffer without being mixed with any other secondary buffers.
Note Software mixing is not optimal and is usually not desired, but if the demands of an application exceed the resources of the hardware, it is an attempt to perform in software tasks the hardware cannot do.
When DirectSound is being initialized for a given device, it will first call IDsDriver::CreateSoundBufferand request the hardware to create the primary buffer. This means the first IDsDriverBufferobject is reserved for the output of the software mixer.
Later, when clients make calls to IDirectSound::CreateSoundBuffer, DirectSound will call down to the driver via IDsDriver::CreateSoundBufferto request a hardware buffer. This buffer will be a hardware secondary buffer. Once all hardware resources are exhausted, future calls to IDsDriver::CreateSoundBufferwill fail. This will cause DirectSound to create software secondary buffers.
Clients can use the DSBCAPS_LOCHARDWARE and DSBCAPS_LOCSOFTWARE flags in the IDirectSound::CreateSoundBuffermethod to optimize their hardware resources. This allows a client application to decide which buffers are in hardware, and which are in software. If the client specifies a buffer be in hardware and the hardware resources are exhausted, the IDirectSound::CreateSoundBuffermethod will fail instead of creating a software buffer.
Last updated on Tuesday, July 13, 2004