Driver-audio MDD and PDD

Most Windows CE device drivers are composed of a platform-related driver (PDD) and a model Device Driver (MDD.Integrated driverCombine all PDD and MDD into one driver.Layered driverThey are not combined.

MDD has the following features:

•	Contains the code shared by all drivers of a given type.
•	Call the PDD function to access hardware.
•	Link to the PDD layer and define the device driver Service Provider Interface (DDSI) function that MDD expects to call in this layer.
•	Expose the device driver interface (DDI) function to the Operating System (OS. Other parts of the OS can call these functions. Related devices can share the same DDI. The integrated driver also discloses the DDI function.
•	Process interrupt processing.
•	It can be reused by developers.
•	It can be linked to multiple PDDs.
•	Generally, no changes are required. If the changes are made, you may encounter problems when migrating the driver to a future version.
•	Contains any interrupt service thread (IST ).

PDD has the following features:

•	It consists of the code unique to the hardware platform.
•	You may need to modify the hardware platform.
•	It is specifically used to use specific MDD implementations.
•	Publish the DDSI function called by MDD. The integrated driver does not disclose DDSI functions.

The following list shows considerations when selecting between a layered driver and an integral driver:

•	The hierarchical driver may only need to modify PDD.
•	The hierarchical driver adds the system overhead for function calling in the device driver, because MDD calls to PDD.
•	The monolithic driver improves the performance of the driver because it combines MDD and PDD into a single layer, which eliminates the function calls by MDD to PDD.
•	It is even harder to migrate an integrated driver to a later version of Windows CE because most of the device drivers included in Windows CE are divided into a PDD and an MDD.
•	If the features of the device match the functions executed by the functions in the MDD layer, the integrated driver can be simpler and more effective.

The source code of any sample driver can be used as the basis for implementation, whether to implement a hierarchical driver or an integral driver.

For more information, see

Windows CE Drivers|Driver Development Tools|Driver Debugging|How to Use the CETK to Test a Driver|Drivers: Post-Development Tasks

As an alternative to directly using the unified audio model (UAM) or implementing stream interfaces, you can use the Model Device Driver (MDD) Library provided by Microsoft. This library implements streaming interface functions through the audio device driver Service Provider Interface (DDSI) function.

If you use Wavemdd. lib, you must create a platform-related driver (PDD) library that matches and implements these audio DDSI functions. The PDD library is usually called Wavepdd. lib (though not required ). The two libraries can then be linked to form an audio driver (often called Wavedev. dll ).

Generally, the audio hardware supports a larger operation set than the file operation set. For example, files do not have volume control or playback speed control, but audio hardware usually has these controls.

Stream interfaceDeviceIOControlSome allow arbitrary operations on the file, so that you can useWAV_IOControlFunction to manipulate the audio hardware. To send commands to the audio hardware, the OS sendsWAV_IOControlVarious messages are transmitted. For example, to prepare the audio hardware for recording, middleware usesWAV_IOControlSend the WIDM_PREPARE message to the audio driver.

Messages sent to audio drivers are similar to those used by user-mode audio drivers (such as Mmdrv. dll) on Windows desktop OS.

Because the audio driver is completely dependent onDeviceIOControlFunction Message, so the implementation of the rest of the stream interface is relatively simple. In particular,WAV_Read,WAV_SeekAndWAV_WriteThe function is only a stub that returns a constant value.

Other stream interface functions should be fully implemented and followMicrosoft Windows ce api Reference.

Displays the interaction of audio drivers using the MDD library.

 

The first step for playing and recording sounds is to create a call from the application to the OS. OS converts such callsWAV_IOControlCall. The OS technology that executes this conversion is Wave API Manager. The audio driver then performs appropriate operations on the hardware.

The Device Manager only loads and registers the audio driver. It does not directly participate in the operation of the driver.

Like the standard streaming interface driver, the audio driver uses the registry key to store configuration information and publish it to the OS.

If the audio driver is not listed in Platform. reg, createHKEY_LOCAL_MACHINE \ Drivers \ Builtin \ AudioRegistry to store configuration information.

When the audio driver is loaded at startup, the Device Manager createsHKEY_LOCAL_MACHINE \ Drivers \ ActiveRegistry key. Because the Device Manager only checks the audio driver at startup, the driver that attaches the audio hardware still needs\ Builtin \ AudioSome have their registry entries, even though their hardware is not built into a Windows CE-based runtime image.

For information about PCI-based Driver Loading models, see PCI Bus Driver Loading Process.

The following list shows the stream interface functions of 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 Driver, see Stream Interface Driver Development Concepts.

The following list shows the DDSI functions of 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.

For more information, see

Audio Driver Development Concepts | Stream Interface Driver Development Concepts