Some ACM drivers may utilize hardware to perform operations on audio data (for example, conversions, compression and decompression, and filtering). The manufacturer of the hardware and ACM driver should develop a Plug and Play driver.
To develop a Plug and Play ACM driver you must first become familiar with device nodes (DevNodes), the Configuration Manager, and the general architecture for multimedia Plug and Play drivers. You must develop a VxD that interacts with the system Configuration Manager, provides access to the hardware, and communicates with the ACM driver DLL. You must write the driver DLL so that it communicates with the VxD for all hardware access. For more information about Windows multimedia Plug and Play drivers, see .
The only detail specific to ACM drivers is the mechanism by which the driver DLL determines the DevNode for which it is being opened. When the ACM opens the driver DLL (even a non - Plug-and-Play DLL), it passes to the driver a pointer to an ACMDRVOPENDESC structure. The driver receives this pointer as the lParam2 parameter of the DRV_OPEN message to its DriverProc function. For Plug and Play drivers, the dnDevNode member of this structure contains an identifier that identifies a DevNode. A DevNode represents a particular instance of hardware in the system. The driver DLL uses this DevNode identifier when it communicates with the VxD. The VxD requires this information when it communicates with Configuration Manager.
Some waveform-audio devices may support wave formats other than PCM formats. For example, the hardare may allow direct playback or recording of a compressed format, such as IMAADPCM or alaw. In this case, the ACM does not have to send the data to an ACM driver once for conversion and then again to the wave driver for playback. Instead the compressed data is sent directly to the wave driver.
If a wave device supports compressed formats, the manufacturer may choose to provide a corresponding ACM driver that supports partial ACM functionality for enumerating formats. This ACM driver would not provide support for compression or decompression, but would instead allow the ACM to recognize that the compressed formats are supported by the wave device. This would allow users of the ACM to recognize that the compressed formats are supported directly by the wave device. The ACM driver messages that should be supported by such a driver are as follows:
The ACM driver can use the ACMDRIVERDETAILS_SUPPORTF_HARDWARE support flag to specify that the format is available for playback, recording, or both. This means that no stream-based operations can be performed. (The ACMDRIVERDETAILS_SUPPORTF_HARDWARE flag is specified in the fdwSupport member of the ACMDRIVERDETAILS structure.)
Some waveform-audio devices may also allow compression or decompression of audio data without requiring that the data be played back or recorded. In other words, it is possible to send data to the device to be compressed but not played. The compressed data can then be read back from the device. This is very similar to a hardware-supported ACM driver. The difference is that the hardware is shared between the wave driver and the ACM driver.
In this case, the wave device manufacturer should provide a VxD (just as for a wave driver or a hardware-supported ACM driver). The manufacturer also provides both a wave driver and an ACM driver (both DLLs). Both the wave driver and the ACM driver communicate with the VxD to allocate the hardware and perform any hardware access. The VxD is responsible for arbitrating hardware access between the wave driver and the ACM driver.