Audio MDD and PDD (Windows CE 5.0)
As an alternative to using the Unified Audio Model (UAM) or implementing the stream interface directly, you can use the model device driver (MDD) library, Wavemdd.lib, supplied by Microsoft. This library implements the stream interface functions through the audio device driver service-provider interface (DDSI) functions.
If you use Wavemdd.lib, you must create a matching platform-dependent driver (PDD) library that implements the audio DDSI functions. The PDD library is generally called Wavepdd.lib, although it is not required. These two libraries can then be linked to form your audio driver, commonly named Wavedev.dll.
Audio hardware typically supports a larger set of operations than those that usually apply to files. For example, files do not have volume controls or playing speed controls, but audio hardware often does.
The DeviceIOControl portion of the stream interface allows arbitrary operations on files, making it possible to manipulate audio hardware using the WAV_IOControl function. To send commands to the audio hardware, the OS passes various messages to WAV_IOControl. For example, to prepare the audio hardware for recording, the middleware uses WAV_IOControl to send the WIDM_PREPARE message to the audio driver.
The messages sent to the audio driver are similar to those used by user-mode audio drivers on Windows-based desktop OSs, such as Mmdrv.dll.
Because audio drivers rely entirely on DeviceIOControl function messages, the implementation of the remainder of the stream interface is relatively simple. Specifically, the WAV_Read, WAV_Seek, and WAV_Write functions are merely stubs that return constant values.
The other stream interface functions should be fully implemented and follow the conventions described in the Microsoft Windows CE API Reference for those functions.
The following illustration shows the interaction of the audio driver using the MDD library.
.gif "ms890671.audio_pdd(en-us,MSDN.10).gif")
As shown in the illustration, the first step in playing and recording sounds is to create a call from an application to the OS. The OS translates such calls into WAV_IOControl calls to the audio driver. The OS technology that performs this translation is the Wave API Manager. The audio driver then executes the appropriate actions on the hardware.
The Device Manager only loads and registers the audio driver; it is not directly involved in the operation of the driver.
Like standard stream interface drivers, the audio driver uses registry keys both to store configuration information and to advertise itself to the OS.
If the audio driver is not already listed in Platform.reg, create a HKEY_LOCAL_MACHINE\Drivers\Builtin\Audio registry key to store configuration information.
The Device Manager creates a HKEY_LOCAL_MACHINE\Drivers\Active registry key for the audio driver when the driver is loaded at startup. Because the Device Manager only checks for audio drivers at startup, drivers for add-on audio hardware still need to have their registry entries in the \Builtin\Audio part of the registry, although their hardware is not built into a Windows CE–based run-time image.
For information about the driver-loading model for PCI-based drivers, see PCI Bus Driver Loading Process.
The following list shows the stream interface functions for the audio driver:
- WAV_Close
- WAV_Deinit
- WAV_Init
- WAV_IOControl
- WAV_Open
- WAV_PowerDown
- WAV_PowerUp
- WAV_Read
- WAV_Seek
- WAV_Write
For more information about these functions, see Waveform Audio Driver Functions. For more information about stream interface drivers, see Stream Interface Driver Development Concepts.
The following list shows the DDSI functions for the audio driver:
- PDD_AudioDeinitialize
- PDD_AudioGetInterruptType
- PDD_AudioInitialize
- PDD_AudioMessage
- PDD_AudioPowerHandler
- PDD_WaveProc
For more information about these functions, see Audio PDD Functions.
See Also
Audio Driver Development Concepts | Stream Interface Driver Development Concepts
Send Feedback on this topic to the authors