Client applications must open an audio device before using it and close the device when finished using it, so the device will be available to other applications. If your device driver will support more than one client simultaneously, you must decide whether the device will return more than one in response to a _GETNUMDEVS message. For example, if your device driver supports multiple clients for simultaneous PCM waveform playback, the device driver might return one for the WODM_GETNUMDEVS message and allow multiple WODM_OPEN messages. Or, if your driver supports completely different playback formats (or routing to different playback hardware), the architecture might be cleaner if each format is treated as a separate device. If you choose to implement your driver as separate devices, you must always check the uDeviceID parameter to determine which device is being accessed. It is also important to set the appropriate DEVCAPS structure so that clients can tell the difference between your devices. For example, a MIDI output driver might support both an external MIDI port and an internal synthesizer. It would make sense to return two for the MODM_GETNUMDEVS message and consider device zero to be the port and device one the synthesizer.
Auxiliary audio devices are handled differently from waveform and MIDI devices. They do not have to be opened, because they do not have the same resource allocation requirements. Also, there is no interrupt level or continuous data transfer associated with auxiliary audio devices.
When a driver receives an open request with one of the_OPEN messages, the dwUser parameter of its entry-point function points to a location that the driver can fill with a DWORD of instance data. This instance data is returned to the driver in the same dwUser parameter when other messages are sent to the driver. Drivers should use this instance data for information related to the client that opened a device.