WASAPI

Source:  Mark .Net http://www.thewelltemperedcomputer.com/KB/WASAPI.htm

WASAPI is a low latency driver when used in exclusive mode talks directly to the
driver of the audio device. It is Microsoft’s own ASIO.
ASIO is a proprietary protocol. You can only use it your audio device supports it.
WASAPI is integral part of Windows (Vista and higher).
In principle it works with all audio devices.
In practice not all combinations of audio applications and audio device drivers will
work correctly using this interface.
 
In exclusive mode, no other application can use the sound card.
No more system sounds at full blast over the stereo!
 
As WASAPI in exclusive mode talks straight to the driver of the audio device, the
stream send to this device must match the capabilities of this device in terms of bit
depth, sample rate, number of channels and audio format (PCM most of the time)
otherwise it is silence.
The application using WASAPI can do this by configuring the audio device to match
the source.
In this case we have bit perfect playback.
This allows for automatic sample rate switching as well.
 
Automatic sample rate switching and hardware
In case of a USB DAC (using native mode drivers) you get automatic sample rate
switching using WASAPI exclusive.
Most of the time the onboard audio allows for automatic sample rate switching as
well.
A lot of discrete sound cards don’t allow automatic switching using WASAPI.
If the discrete sound card comes with ASIO, you better use this driver if you want
automatic sample rate switching.
The developer can also choose to adept the source to the capabilities of the audio
device.
If the source is mono and the audio device 2 channel, the developer might decide to
send the same signal to both channels.
If the sample rate of the source is not supported by the hardware e.g. 192 kHz source
with a 96 kHz audio device, the program using WASAPI has to do the SRC (Sample
Rate Conversion).
This can be done by calling the SRC provided by Windows or one provided by the
application.

Windows audio architecture

Vista has a completely  new audio mixing engine, so WASAPI gives you the chance to
plug directly into it rather than going through a layer of abstraction. The reasons for
the new audio engine are:

 A move to  32 bit floating point  rather than 16 bit, which greatly improves
audio quality when dealing with multiple audio streams or effects.
 A move from kernel mode into  user mode  in a bid to increase system stability
(bad drivers can't take the system down).
 The concept of  endpoints  rather than audio devices - making it easier for
Windows users to send sounds to "headphones" or record sound from "microphone"
rather than requiring them to know technical details about the soundcard's
installed on their system
 Grouping audio streams. In Vista, you can group together all audio streams
out of a single application and control their volume separately. In other words, a
per-application volume control. This is a bit more involved than might be at first
thought, because some applications such as IE host all kinds of processes and
plugins that all play sound in their own way.
 Support pro audio applications which needed to be as close to the metal as
possible, and keep  latency  to a bare minimum. (see Larry Osterman's  Where does
WASAPI fit in the big multimedia API picture?)

Windows audio diagram  (Vista and higher)

 
By default all sounds are send to the mixer.
The mixer converts the audio to 32 bit float and does the mixing.
The result is dithered and converted back to a format the audio driver accepts (most
of the time 16 or 24 bit).
 
The applications sending sound to the mixer must see to it that the sample rate
matches the default rate of the mixer. This default is set in the Advanced tab of the
audio panel.
Even if the source matches the default sample rate, dithering will be applied.
Q: If you
•don't apply any per-stream or global effects and
•only have one application outputting audio and
•the sample rate and bit-depth set for the sound card matches the material's sample
rate
then there should theoretically be no difference to the original because a conversion
from even 24-bit integer to 32-bit float is lossless.
 
A: Not quite. Since we can not assure that there was nothing added, no gain controls
changed, etc, we must dither the final float->fix conversion, so you will incur one step
of dithering at your card's level. As annoying as this is for gain=1 with single sources,
we can't possibly single-source in general.
If you don't want even that, there is exclusive mode, which is roughly speaking a
memcopy.
J. D. (JJ) Johnston

Exclusive mode
WASAPI in exclusive mode bypasses the audio engine (the mixer).
The conversion to 32 float and the dither as applied by the mixer are avoided.
It also locks the audio driver; no other application can use the audio device.

Shared mode
This is equivalent to DS (Direct Sound).
All audio is send to the mixer.
The application must invoke sample rate conversion if the sample rate differs from
the value set in the win audio panel.
Typically, the application is responsible for providing the Audio Engine audio buffers in
a format that is supported by the Audio Engine. Audio sample formats consist of the
sampling frequency, the bit depth, and the number of channels. The native bit depth of
samples that the Audio Engine uses internally is 32-bit float. However, the Audio
Engine accepts most integer formats that are up to 32-bits. Additionally, the Audio
Engine converts most formats to the floating point representation internally. The Audio
Control Panel specifies the required sampling frequency as the “Default format.” The
Default format specifies the format that is used to provide the content by the audio
device. The number of channels that the Audio Engine supports is generally the number
of speakers in the audio device.

Changing the sampling frequency and data bit depth is called sample rate conversion.
An application may decide to write its own sample rate converter. Alternatively, an
application may decide to use APIs such as PlaySound, WAVE, Musical Instrument
Digital Interface (MIDI), or Mixer. In these APIs, the conversion occurs automatically.
When it is required, Windows Media Player performs sample rate conversion in its
internal Media Foundation pipeline. However, if Windows Media Player is playing audio
that the Audio Engine can handle natively, Windows Media Player rebuilds its own
pipeline without a sample rate converter. This behavior occurs to reduce the
intermediate audio transformations and to improve performance.
Microsoft
 

Event style
WASAPI can be used in push and in pull mode (event style).
A couple of asynchronous USB DAC’s had all kind of problems using push mode due
to buffer problems in WASAPI.
This has been solved by using WASAPI – Event style.
The audio device pulls the data from the system.
 
Most of the time you can't choose the mode. It simply depends on how the
programmer implemented WASAPI in the media player.
 
The difference between doing push or doing event is only who is responsible to know
when the host has to send audio to the hardware.

Event based:

- Host tells API that it wants to be informed when it is the appropiate moment to send
audio
- Host might prepare some audio in a separate thread so that it is ready when the API
asks for it
- API asks host for more audio
- Host sends the prepared buffer if it was ready, or prepares then the buffer and sends
it.

Push based:

- Host tells API that it will ask when it is the appropiate moment to send the audio.
- Hosts prepares some audio so that it is ready when the API is ready.
- Hosts asks the API if it is ready.
- If it is not ready, waits some time, and asks again
- When the API replies that it is ready, the host sends the prepared buffer. It might also
prepare the buffer at this time and send it.
[JAZ]
 
WASAPI - Event Style
The output mode lets a sound device pull data from Media Center. This method is not
supported by all hardware, but is recommended when supported.
WASAPI - Event Style has several advantages:

 It lets the audio subsystem pull data (when events are set) instead of pushing
data to the system. This allows lower latency buffer sizes, and removes an
unreliable Microsoft layer.
 It creates, uses, and destroys all WASAPI interfaces from a single thread.
 The hardware (or WASAPI interface) never sees any pause or flush calls. Instead,
on pause or flush, silence is delivered in the pull loop. This removes the need for
hacks for cards that circle their buffers on pause, flush, etc. (ATI HDMI, etc.).
 It allows for a more direct data path to the driver / hardware.
 The main 'pull loop' uses a lock-free circle buffer (a system that J. River built for
ASIO), so that fullfilling a pull request is as fast as possible.

WASAPI  – JRiver Wiki

Practice
Using WASAPI requires a media player supporting this driver in exclusive mode.
Players like MusicBee or Foobar do, WMP don’t.
 
I do think WASAPI exclusive sounds a bit more transparent than DS (Direct Sound),
the Win default audio engine.
However, as all that is send to the audio endpoint must match the capabilities of this
device exactly, WASAPI is also more troublesome. The slightest mismatch in number
of channels, bit depth or sample rate and it is silence or static.
 
Configure your media player for WASAPI and DS and do a listening test.
If you don’t hear a difference, stick to DS.
If you do hear a difference, use the one you prefer.
 
WASAPI in general don't work with discrete sound cards.
In case of a USB DAC it is the way to go.

Conclusion
WASAPI is a low latency interface to the driver of the audio device.
Bypassing the mixer is all what it does.
It is up to the developer or the user of the application using WASAPI to see to it that
the properties of the audio file and the capabilities of the audio device do match.
References

1. User-Mode Audio Components - MSDN

2. Exclusive-Mode Streams - MSDN
3. What's up with WASAPI? - Mark Heath
4. Where does WASAPI fit in the big multimedia API picture? - Larry Osterman
5. WASAPI – JRiver Wiki
User-Mode Audio Components
2018. 05. 31 https://docs.microsoft.com/hu-hu/windows/win32/coreaudio/user-mode-audio-components?redirectedfrom=MSDN

In Windows Vista, the core audio APIs serve as the foundation of the user-mode
audio subsystem. The core audio APIs are implemented as a thin layer of user-mode
system components that separate user-mode clients from kernel-mode audio drivers
and audio hardware. Higher-level audio APIs, such as DirectSound and the Windows
multimedia functions, access audio devices through the core audio APIs. In addition,
some audio applications communicate directly with the core audio APIs.

The core audio APIs support the user-friendly notion of an audio endpoint device. An
audio endpoint device is a software abstraction that represents a physical device that
the user manipulates directly. Examples of audio endpoint devices are speakers,
headphones, and microphones. For more information, see Audio Endpoint Devices.

The following diagram shows the core audio APIs and their relationship to the other
user-mode audio components in Windows Vista.

For simplicity, the preceding diagram shows only an audio-rendering data path to the
endpoint device—the diagram does not show an audio-capture data path. The core
audio APIs include the MMDevice API, WASAPI, the DeviceTopology API, and
the EndpointVolume API, which are implemented in the Audioses.dll and
Mmdevapi.dll user-mode system modules.

As shown in the preceding diagram, the core audio APIs provide a foundation for the
following higher-level APIs:

 Media Foundation
 Windows multimedia waveXxx and mixerXxx functions
 DirectSound
 DirectMusic

DirectSound, the Windows multimedia audio functions, and Media Foundation

(through its streaming audio renderer, or SAR, component) communicate directly
with the core audio APIs. DirectMusic communicates with the core audio APIs
indirectly through DirectSound.

A client of WASAPI passes data to an endpoint device through an endpoint buffer.

System software and hardware components manage the movement of data from the
endpoint buffer to the endpoint device in a manner that is largely transparent to the
client. Furthermore, for an endpoint device that plugs into an audio adapter with
jack-presence detection, the client can create an endpoint buffer only for an endpoint
device that is physically present. For more information about jack-presence detection,
see Audio Endpoint Devices.

The preceding diagram shows two types of endpoint buffer. If a client of WASAPI
opens a stream in shared mode, then the client writes audio data to the endpoint
buffer and the Windows audio engine reads the data from the buffer. In this mode,
the client shares the audio hardware with other applications running in other
processes. The audio engine mixes the streams from these applications and plays the
resulting mix through the hardware. The audio engine is a user-mode system
component (Audiodg.dll) that performs all of its stream-processing operations in
software. In contrast, if a client opens a stream in exclusive mode, the client has
exclusive access to the audio hardware. Typically, only a small number of "pro audio"
or RTC applications require exclusive mode. Although the diagram shows both the
shared-mode and exclusive-mode streams, only one of these two streams (and its
corresponding endpoint buffer) exists, depending on whether the client opens the
stream in shared mode or in exclusive mode.

In exclusive mode, the client can choose to open the stream in any audio format that
the endpoint device supports. In shared mode, the client must open the stream in the
mix format that is currently in use by the audio engine (or a format that is similar to
the mix format). The audio engine's input streams and the output mix from the
engine are all in this format.
In Windows 7, a new feature called low-latence mode has been added for streams in
share mode. In this mode, the audio engine runs in pull mode, in which there a
significant reduction in latency. This is very useful for communication applications
that require low audio stream latency for faster streaming.

Applications that manage low-latency audio streams can use the Multimedia Class
Scheduler Service (MMCSS) in Windows Vista to increase the priority of application
threads that access endpoint buffers. MMCSS enables audio applications to run at
high priority without denying CPU resources to lower-priority applications. MMCSS
assigns a priority to a thread based on its task name. For example, Windows Vista
supports the task names "Audio" and "Pro Audio" for threads that manage audio
streams. By default, the priority of a "Pro Audio" thread is higher than that of an
"Audio" thread. For more information about MMCSS, see the Windows SDK
documentation.

The core audio APIs support both PCM and non-PCM stream formats. However, the
audio engine can mix only PCM streams. Thus, only exclusive-mode streams can have
non-PCM formats. For more information, see Device Formats.

The audio engine runs in its own protected process, which is separate from the
process that the application runs in. To support a shared-mode stream, the Windows
audio service (the box labeled "Audio Service" in the preceding diagram) allocates a
cross-process endpoint buffer that is accessible to both the application and the audio
engine. For exclusive mode, the endpoint buffer resides in memory that is accessible
to both the application and the audio hardware.

The Windows audio service is the module that implements Windows audio policy.
Audio policy is a set of internal rules that the system applies to the interactions
between audio streams from multiple applications that share and compete for use of
the same audio hardware. The Windows audio service implements audio policy by
setting the control parameters for the audio engine. The duties of the audio service
include:

 Keeping track of the audio devices that the user adds to or removes from the
system.
 Monitoring the roles that are assigned to the audio devices in the system.
 Managing the audio streams from groups of tasks that produce similar classes
of audio content (console, multimedia, and communications).
 Controlling the volume level of the combined output stream ("submix") for
each of the various types of audio content.
 Informing the audio engine about the processing elements in the data paths
for the audio streams.
In some versions of Windows, the Windows audio service is disabled by default and
must be explicitly turned on before the system can play audio.

In the example shown in the preceding diagram, the endpoint device is a set of
speakers that are plugged into the audio adapter. The client application writes audio
data to the endpoint buffer, and the audio engine handles the details of transporting
the data from the buffer to the endpoint device.

The box labeled "Audio Driver" in the preceding diagram might be a combination of
system-supplied and vendor-supplied driver components. In the case of an audio
adapter on a PCI or PCI Express bus, the system supplies the Port Class system driver
(Portcls.sys), which implements a set of port drivers for the various audio functions in
the adapter, and the hardware vendor supplies an adapter driver that implements a
set of miniport drivers to handle device-specific operations for the port drivers. In the
case of a High Definition Audio controller and codec on a PCI or PCI Express bus, the
system supplies the adapter driver (Hdaudio.sys), and no vendor-supplied driver is
needed. In the case of an audio adapter on a USB bus, the system supplies the
AVStream class system driver (Ks.sys) plus the USB Audio driver (Usbaudio.sys); again,
no vendor-supplied driver is needed.

For simplicity, the preceding diagram shows only rendering streams. However, the
core audio APIs support capture streams as well. In shared mode, several clients can
share the captured stream from an audio hardware device. In exclusive mode, one
client has exclusive access to the captured stream from the device.
Audio Endpoint Devices
2018. 05. 31. https://docs.microsoft.com/hu-hu/windows/win32/coreaudio/audio-endpoint-devices

The term endpoint device refers to a hardware device that lies at one end of a data
path that originates or terminates at an application program. Examples of audio
endpoint devices are speakers, headphones, microphones, and CD players. The audio
data that moves along the data path might traverse a number of software and
hardware components during its journey between the application and endpoint
device. Although these components are essential to the operation of the endpoint
device, they tend to be invisible to users. Users are more likely to think in terms of
endpoint devices that they directly manipulate rather than in terms of the devices on
audio adapters that the endpoint devices plug into or in terms of the software
components that process the audio streams that flow to and from these adapters.

To avoid confusion with endpoint devices, this documentation refers to a device on

an audio adapter as an adapter device.

The following diagram shows how audio endpoint devices differ from adapter
devices.

In the preceding diagram, the following are examples of endpoint devices:

 Speakers
 Microphone
 Auxiliary input device

The following are examples of adapter devices:

  Wave output device (contains digital-to-analog converter)
 Output controls device (contains volume and mute controls)
 Wave input device (contains analog-to-digital converter)
 Input controls device (contains volume control and multiplexer)

Typically, the user interfaces of audio applications refer to audio endpoint devices,
not to adapter devices. Windows Vista simplifies the design of user-friendly
applications by directly supporting the endpoint device abstraction.

Some endpoint devices might permanently connect to an adapter device. For

example, a computer might contain internal devices such as a CD player, a
microphone, or speakers that are integrated into the system chassis. Typically, the
user does not physically remove these endpoint devices.

Other endpoint devices might connect to an audio adapter through audio jacks. The
user plugs in and unplugs these external devices. For example, an audio endpoint
device such as an external microphone or headphones lies at one end of a cable
whose other end plugs into a jack on an adapter device.

The adapter communicates with the system processor through a system bus
(typically, PCI or PCI Express) or external bus (USB or IEEE 1394) that supports Plug
and Play (PnP). During device enumeration, the Plug and Play manager identifies the
devices in the audio adapter and registers those devices to make them available for
use by the operating system and by applications.

Unlike the connection between an adapter and an external bus such as USB or the
IEEE 1394 bus, the connection between an endpoint device and an adapter device
does not support PnP device detection. However, some audio adapters support jack-
presence detection: when a plug is inserted into or removed from a jack, the hardware
generates an interrupt to notify the adapter driver of the change in the hardware
configuration. The endpoint manager in Windows Vista can exploit this hardware
capability to notify applications which endpoint devices are present at any time. In
this way, the operation of the endpoint manager is analogous to that of the Plug and
Play manager, which keeps track of the adapter devices that are present in the
system.

In Windows Vista, the audio system keeps track of both endpoint devices and adapter
devices. The endpoint manager registers endpoint devices and the Plug and Play
manager registers adapter devices. Registering endpoint devices makes it easier for
user-friendly applications to enable users to refer to the endpoint devices that users
directly manipulate instead of referring to adapter devices that might be hidden
inside the computer chassis. The endpoint devices that are reported by the operating
system faithfully track dynamic changes in the configuration of audio hardware that
has jack-presence detection. While an endpoint device remains plugged in, the
system enumerates that device. When the user unplugs an endpoint device, the
system ceases to enumerate it.

In earlier versions of Windows, including Windows 98, Windows Me, Windows 2000,
and Windows XP, the system explicitly presents only PnP devices to applications.
Thus, applications must infer the existence of endpoint devices. An operating system
that lacks explicit support for endpoint devices forces client applications to do more
of the work themselves. For example, an audio capture application must perform the
following steps to enable capturing from an external microphone:

1. Enumerate all the audio capture devices (these are adapter devices) that were
previously registered by the PnP manager.
2. After selecting a capture device, open a capture stream on the device by either
calling the waveInOpen function or by using the DirectSoundCapture or
DirectShow API.
3. Call the mixerOpen function and use the other mixerXxx functions to look for
a MIXERLINE_COMPONENTTYPE_SRC_MICROPHONE line that corresponds to
the capture device opened in step 2. This is an educated guess.
4. Unblock the data path from the microphone. If the data path includes a mute
node, then the client must disable muting of the signal from the microphone. If
the capture device contains a multiplexer for selecting from among several
inputs, then the client must select the microphone input.

This process is error-prone because the software that performs these operations
might fail if it encounters a hardware configuration that its designers did not
anticipate or for which it was not tested.

In Windows Vista, which supports endpoint devices, the process of connecting to the
same endpoint device is much simpler:

1. Select a microphone from a collection of endpoint devices.

2. Activate an audio-capture interface on that microphone.

The operating system does all the work necessary to identify and enable the endpoint
device. For example, if the data path from the microphone includes a multiplexer, the
system automatically selects the microphone input to the multiplexer.

The behavior of the audio subsystem is more reliable and deterministic if

applications, instead of implementing their own endpoint-identification algorithms,
can relegate the task of identifying endpoint devices to the operating system.
Software vendors no longer need to verify that their endpoint-identification
algorithms work correctly with all available audio hardware devices and
configurations—they can simply rely on the operating system for endpoint
identification. Similarly, hardware vendors no longer need to verify that every relevant
client application can readily identify any endpoint device that is connected to their
audio adapter—they need only to verify that the operating system can identify an
endpoint device that is connected to their audio adapter.

The following topics provide additional information about audio endpoint devices:

 About MMDevice API

 Enumerating Audio Devices
 Endpoint ID Strings
 Device Properties
 Device Events
 Device Roles
 Device Formats
Audio Processing Object Architecture
10/18/2019 https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/audio-processing-object-architecture

Audio processing objects (APOs), provide customizable software based digital signal
processing for Windows audio streams.

Audio Processing Objects Overview

Windows allows OEMs and third-party audio hardware manufacturers to include
custom digital signal processing effects as part of their audio driver's value-added
features. These effects are packaged as user-mode system effect Audio Processing
Objects (APOs).

Audio processing objects (APOs), provide software based digital signal processing for
Windows audio streams. An APO is a COM host object that contains an algorithm
that is written to provide a specific Digital Signal Processing (DSP) effect. This
capability is known informally as an "audio effect." Examples of APOs include graphic
equalizers, reverb, tremolo, Acoustic Echo Cancellation (AEC) and Automatic Gain
Control (AGC). APOs are COM-based, real-time, in-process objects.

Note   The descriptions and terminology in this documentation refers mostly to

output devices. However, the technology is symmetric and works essentially in
reverse for input devices.

Software APOs vs. Hardware DSP

A hardware digital signal processor (DSP) is a specialized microprocessor (or a SIP

block), with its architecture optimized for the operational needs of digital signal
processing. There can be significant advantages to implement audio processing in
purpose built hardware vs. using a software APO. One advantage is that the CPU use
and associated power consumption may be lower with a hardware implemented DSP.

There are other advantages and disadvantages to consider, specific to your projects
goals and constraints that you will want to consider before implementing a software
based APO.

Software based effects are inserted in the software device pipe on stream
initialization. These solutions do all their effects processing on the main CPU and do
not rely on external hardware. This type of solution is best for traditional Windows
audio solutions such as HDAudio, USB and Bluetooth devices when the driver and
hardware only support RAW processing. For more information about RAW
processing, see Audio Signal Processing Modes.
Proxy APO for Hardware DSP

Any effects applied in hardware DSP need to be advertised via a proxy APO.
Microsoft provides a default proxy APO (MsApoFxProxy.dll). To use the Microsoft
provided APO, this property set and property must be supported.

 KSPROPSETID_AudioEffectsDiscovery
 KSPROPERTY_AUDIOEFFECTSDISCOVERY_EFFECTSLIST

Optionally, you can implement your own proxy APO.

Windows Provided (System) APOs

Windows installs a default set of APOs, that provide a number of different audio
effects. For a list of the system provided APO effects, see Audio Signal Processing
Modes.

OEMs can include all of the system supplied APOs or replace some or all of them with
custom APOs.

Custom APOs

It is possible to create custom APOs to enhance the Windows audio experience by

adding additional audio effects.

The OEM can include any combination of the provided Windows APOs and custom
APOs when they ship Windows.

A custom APO can be installed by an OEM or a third-party to enhance the audio

experience after the device has been purchased. When users install an audio device
driver by using the standard INF file, they automatically have access to the system's
APOs. Independent hardware vendors (IHVs) and original equipment manufacturers
(OEMs) can provide additional custom system effects while still using the Microsoft
class drivers. They do so by packaging their DSP algorithms as APOs and modifying
the standard INF file to insert their APOs into the audio engine’s signal processing
graph.

For more information on creating custom APOs see, Implementing Audio Processing

Objects.

Custom APO Support App

To allow the user to configure settings associated with your custom APO the
recommended approach is to create a Hardware Support App. For more information,
see Hardware Support App (HSA): Steps for Driver Developers.
Custom APO Tests and Requirements

The Microsoft HLK provides tests that can be used with APOs. For more information
about audio tests see, Device.Audio Testing and Device.Audio Tests.

These two tests can be particularly useful when working with APOs.

Verify Audio EffectsDiscovery (Manual) - Certification

SysFX Test

For information on audio requirements to support APOs, see Device.Audio

Requirements.

Custom APO Tools and Utilities

You can use the "Audio Effects Discovery Sample" to explore the available audio
effects. This sample demonstrates how to query audio effects on render and capture
audio devices and how to monitor changes with the audio effects. It is included as
part of the SDK samples and can be downloaded using this link:

Audio effects discovery sample

Application Audio Effect Awareness

Applications have the ability to call APIs to determine which audio effects are
currently active on the system. For more information on the audio effects awareness
APIs, see AudioRenderEffectsManager class.

Audio Processing Objects Architecture

Placement of Audio Effects

There are three different locations for audio effects implemented as APOs. They are in
Stream effects (SFX), Mode effects (MFX), and Endpoint effects (EFX).

Stream Effect (SFX)

A stream effect APO has an instance of the effect for every stream. Stream effects are
before the mix (render) or after the tee (capture) for a given mode and can be used
for changing channel count before the mixer. Stream effects are not used for raw
streams.

Some versions of Windows, as an optimization, do not load SFX or MFX APOs in RAW
mode.
  Windows 8.1 does not load RAW SFX or RAW MFX
 Windows 10 loads RAW MFX but not RAW SFX

Mode Effect (MFX)

Mode effects (MFX) are applied to all streams that are mapped to the same mode.
Mode effects are applied after the mix (render) or before the tee (capture) for a given
mode, but before the mix (render) or after the tee (capture) of all modes. Any
scenario specific effect or effect that doesn’t need the specifics of the stream effect
should be placed here. It is more power efficient to use a mode effect since there is
one instance for multiple streams that share the same characteristics like periodicity
and format.

Endpoint Effect (EFX)

Endpoint Effect (EFX) are applied to all streams that use the same endpoint. An
endpoint effect is always applied, even to raw streams. That is, it is after the mix
(render) or before the tee (capture) of all modes. The endpoint effects should be used
with care and when in doubt an effect should be place in the Mode area. Some
effects that should be placed in the endpoint area are speaker protection and speaker
compensation.

This diagram shows the possible locations for stream (SFX), mode (MFX) and
endpoint (EFX) effects for Windows 10.

Multiple Custom APO Effects

It is possible to configure multiple APO based effects to work with different

applications.
This diagram illustrates how multiple applications can access multiple combinations
of stream, mode and endpoint APO effects. All of the APOs are COM based and run
in user mode. In this scenario, none of the effects are running in hardware or in kernel
mode.

Note  You can use the scroll bar at the very bottom of this page to view all of this
diagram.

Software Mode Effects and Hardware Endpoint Effects for Render and Capture

This diagram illustrates software mode effects and hardware endpoint effects for
render and capture.
DSP Equipped System with Hardware Effects

This diagram illustrates a DSP equipped system that implements effects in hardware.
In this scenario, a Proxy APO should be created to inform the apps of the effects that
are implemented in hardware.