Windows peculiarities and bugs

The system unconditionally assigns the default endpoint

When a new audio device is installed, the system may unconditionally select one of its endpoints as a default endpoint, instead of the previously assigned one. Microsoft explains this behavior by what the user usually expects the newly installed device to be ready to use immediately, without additional actions. In most cases, it is true, but there is no way to control the behavior. The system makes the decision solely on its discretion, using a hard-coded heuristics.

The "Listen" feature does not change target endpoint on default endpoint change

If a default playback endpoint is selected as a target for the "Listen" feature, and default playback endpoint is changed, target playback endpoint is not changed, and audio stream is still transferred to the same target endpoint.

Systems affected: Windows 10/1903, Windows 10/1909, maybe later versions too.

The "Listen" feature does not properly track connection events

If an audio device is connected or disconnected, the "Listen" feature may become unstable, working only for some endpoint pairs, or stop working at all. In some cases, changing input/output endpoints can help, but not always. Restart of the Audio Service that manages audio data transfer, does not help. Only system restart restores normal behavior.

Systems affected: Windows 7 and later (up to Windows 11).

System Audio Engine does not open a capture pin if instance count is nonzero

If a KS/WDM driver reports that there are available capture pin instances (KSPROPERTY_PIN_GLOBALCINSTANCES property request returns PossibleCount greater than CurrentCount), System Audio Engine does not create a pin instance if CurrentCount is nonzero.

In accordance with Microsoft documentation, PossibleCount values greater than CurrentCount mean that there are available pin instances, and the driver will satisfy a stream creation request.

Microsoft developers explain this Audio Engine behavior by the desire to avoid possible problems with multiplexed pins.

In VAC 4.70, a workaround was added for this bug.

Systems affected: All systems from Windows Vista.

Channel peak values are not processed properly

Channel peak values (IAudioMeterInformation::GetChannelsPeakValues) may not be returned, and live peak indicators may not be shown in audio endpoint property windows even if the driver supports KSPROPERTY_AUDIO_PEAKMETER2 property request.

This bug occurs if the driver supports KSPROPERTY_AUDIO_PEAKMETER2 property request and supports more than two audio channels. The basic KSPROPERTY_AUDIO_PEAKMETER request is processed properly regardless of number of channels supported. If the driver supports both KSPROPERTY_AUDIO_PEAKMETER and KSPROPERTY_AUDIO_PEAKMETER2, systems starting from WIndows 8 use KSPROPERTY_AUDIO_PEAKMETER2.

Systems affected: Windows 10 from 1803.

The "Levels" tab of audio properties window crashes if the filter supports more than 8 channels

In playback endpoint properties, opening the "Levels" tab may crash the property window if the appropriate filter supports more than 8 audio channels.

Systems affected: all systems starting from Windows Vista.

RT Audio buffer created by a KS/WDM driver is much larger than requested

If an audio client requests a circular buffer in RT Audio protocol from a KS/WDM driver, the driver may return much larger buffer. For example, if 1920-byte buffer is requested, 4096 byte-buffer may be returned. If 5760-byte buffer is requested, 12288-byte buffer may be returned.

The problem affects all PortCls miniport drivers if a simple circular buffer without notifications is requested (KSPROPERTY_RTAUDIO_BUFFER property request). In such case, PortCls forcibly rounds the requested buffer size up to a least common multiple of the page size (4096 bytes) and the frame size of the stream audio format. This may lead to increased latency.

If the client requests a buffer with notifications (KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION property request), no size adjustment is performed by PortCls (but the device driver itself may adjust buffer size as well).

Since version 4.71, VAC driver may adjust the buffer itself, regardless of its type. It might cause unexpected behavior of the Audio Engine, so VAC driver doesn't adjust buffers requested by the Engine.

Systems affected: all systems starting from Windows Vista.

If the driver adjusts the size of RT Audio buffer while creating it, Audio Engine may fail the request

When the System Audio Engine requests a render/playback RT Audio circular buffer from an audio driver, it usually doesn't tolerate possible increasing of the duration/size of the buffer. Both KSPROPERTY_RTAUDIO_BUFFER and KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION requests allow the driver to return a buffer longer/larger than requested, but the Engine accepts a larger buffer only for KSPROPERTY_RTAUDIO_BUFFER requests. If the driver returns a larger buffer from KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION request, the Engine often fails the request from  its primary client (the audio application) with error code 0x887C0054. In some versions of Windows, the Engine calculates and saves the new value of its default processing period to use it for the next requests, so repeated stream creation attempt completes successfully. However, in other versions, the Engine continues to fail stream creation requests every time.

To avoid such unpredictable behavior, VAC driver doesn't adjust RT buffer duration/size for the Audio Engine process (audiodg.exe).

Systems affected: all systems starting from Windows 7.

System audio services send KSPROPERTY_PIN_PROPOSEDATAFORMAT requests with invalid parameters

System audio services that use MMDevAPI.dll may send many KSPROPERTY_PIN_PROPOSEDATAFORMAT property requests with invalid parameters passed in KSDATAFORMAT descriptor. Audio drivers that carefully check all the parameters, fail all these requests. Drivers that don't check all the parameters, may misbehave or even crash.

In most cases, invalid FormatSize, and arbitrary Flags and SampleSize values are provided. In the Flags, arbitrary values often contain KSDATAFORMAT_ATTRIBUTES flag, causing the driver to interpret the data beyond the KSDATAFORMAT descriptor as a format attribute list.

Such errors often occur with multi-channel (having more than two channels) formats. VAC driver event log may contain records marked with "*" that indicates an error, and containing words "attribute" or "KSDATAFORMAT".

As a workaround, VAC driver supports format attribute policies.

Systems affected: all systems starting from Windows Vista.