ACM Driver Development (Windows CE 5.0)
The following list details several key reasons to write an ACM driver:
- To support a particular audio file format. For example, audio files in other formats need customized ACM drivers.
- To convert audio file format to another format. The ACM driver APIs can be used to load an audio file into a common format, which ACM drivers can then translate into their own format.
- To use an encoding or compression algorithm tailored to the characteristics of a particular type of audio. For example, human speech has a relatively limited frequency range and many essentially silent periods. An ACM driver written with these characteristics in mind can produce recordings that require little memory and yet retain good sound quality.
- To perform filtering of audio data. For example, an ACM driver could be used to filter a data stream out of an audio signal that contains speech in the lower frequencies and data in the higher frequencies.
An individual ACM driver can be written to perform a combination of these tasks.
All ACM drivers must use ACM as their device file name prefix.
In Windows CE, the Index keys in the registry settings designate individual ACM drivers. Thus, multiple ACM drivers have special device file names, such as ACM1:, ACM2:, and so on.
A maximum of eight ACM drivers can coexist on a Windows CE–based run-time image; Index value 9 is reserved for the PCM converter exported from Waveapi.dll.
The ACM uses Index keys when searching for an ACM driver to perform format conversions. The ACM selects the first appropriate ACM driver that it finds. For more information on device file names and Index keys, see Stream Interface Driver Development Concepts.
ACM drivers respond to messages similar to those used by ACM drivers written for the desktop. In fact, the Windows CE–based ACM functions and structures that ACM drivers use, are the same as those described in the Microsoft® Windows NT® Driver Development Kit (DDK).
In Windows CE, the ACM uses the ACM_IOControl function to send messages to the driver. By calling this function, the ACM bypasses the three primary stream I/O functions: XXX_Read (Device Manager), XXX_Write (Device Manager), and XXX_Seek (Device Manager).
Consequently, those functions are never called in an ACM driver. The ACM uses the other stream I/O functions only for setup and shutdown tasks.
The Microsoft Windows NT DDK contains several sample ACM drivers. You can port these drivers to work on any Windows CE–based run-time image that your product targets, and you can modify the drivers to support additional audio format types and audio filter types. The Microsoft Windows NT DDK contains complete documentation on writing ACM drivers.
For more information, see Porting a Desktop ACM Driver to Windows CE.
Send Feedback on this topic to the authors