Tutorials > How to enumerate audio input devices

By default Audio Sound Recorder for .NET enumerates input devices (sound cards) supporting the DirectSound protocol and the standard way to enumerate input devices is the combination of GetInputDevicesCount and GetInputDeviceDesc methods but, in order to let Audio Sound Recorder enumerating devices supporting ASIO drivers or WASAPI drivers (only on Windows Vista and later versions), you need to make a prior call to the InitDriversType method and to specify which kind of drivers/protocols your application will support.

IMPORTANT NOTE: When using the Audio Sound Recorder component in conjunction with our Audio DJ Studio component, which also contains the InitDriversType method, it should be preferred calling the InitDriversType method from Audio DJ Studio so it will automatically affect both input and output devices.

The call to the InitDriversType method is mandatory before performing calls to the InitRecordingSystem, GetInputDevicesCount and GetInputDeviceDesc methods: if the InitDriversType method should be called at a later time, it would report back an error; if for any reason you should need calling it at a later time, you would need performing the following sequence of calls:

1. ResetEngine method

2. InitDriversType method

3. Eventual new enumeration of input devices through the GetInputDevicesCount and GetInputDeviceDesc methods.

4. ResetControl method

After having initialized the type of driver(s) in use through the InitDriversType method, it will be possible enumerating available input devices through the GetInputDevicesCount and GetInputDeviceDesc methods: depending upon the kind of drivers in use, these methods will return the overall list of available input devices.

When using ASIO and WASAPI drivers you can have more control over audio devices enumeration through a set of dedicated methods: refer to the How to manage ASIO drivers and How to manage audio flow through WASAPI tutorials for further details.

The full sequence of calls for enumerating audio input devices for recording purposes, keeping count of selected drivers type, is explained inside the How to perform a recording session tutorial.

The configuration of audio devices is not static: for example when dealing with USB connected audio devices the configuration may change when a USB device is plugged/unplugged or, when dealing with Windows Vista and later versions which support jack-sensing, when the microphone's jack is inserted or removed from its connector. Let's see what may happen depending upon the Windows version in use:

Configuration change in Windows XP, Windows Server 2003 and older versions

When a new USB device is plugged-in or unplugged, the container application receives one or more DeviceChange events: after receiving this event, if you need to remain in sync with available sound cards, you will have to reset the multimedia engine with the procedure described above. Windows XP doesn't support jack-sensing so you won't be notified when the Microphone or Line-In jacks are unplugged.

As mentioned, you could receive more than one DeviceChange event at the same time so, when starting the reset procedure, you should ignoreDeviceChange events after the first one.

Configuration change in Windows Vista and later versions

In case a USB audio device should be added to the system, for example when an USB sound card is installed for the first time, the container application can be informed in real time by catching the CoreAudioDeviceAdded event.

When a device has been added to the system, it may still be reported as "Disabled" due to the jack-sensing feature that keeps a device disabled until the Microphone or the Line-In jack are not physically plugged into the system; when the audio device is set as "Enabled" or "Disabled", one or more CoreAudioDeviceStateChange events could be generated.

If the USB audio device should be uninstalled from the system, by physically removing the audio device and by uninstalling its driver from the system, the CoreAudioDeviceRemoved event would be generated.

As mentioned, you could receive more than one CoreAudioDeviceStateChange event at the same time so, when starting the reset procedure, you should ignore CoreAudioDeviceStateChange events after the first one.