USB Audio 2.0 Drivers - Windows drivers
Driver on

Audio subsystem power management for modern standby platforms

Each Home windows PC has an audio subsystem that permits the person to take heed to and document high-quality sound in real-time. A {hardware} platform that helps the related standby energy mannequin is usually constructed round a System on a Chip (SoC) built-in circuit that options built-in, low-power audio processing items.

The audio processing items offload audio processing from the principle processor (or processors) on the SoC. As a result of these items can course of audio information with out utilizing the principle processor, the person can proceed to take heed to audio even after the principle processor enters a low-power state to preserve battery energy.

This video exhibits learn how to use Home windows Efficiency Analyzer (WPA) to confirm that a pc enters the low-power state throughout screen-off audio playback (often known as low-power audio, or LPA).

The next article discusses audio subsystem energy administration for related standby platforms. Within the following dialogue, the time period on-SoC element describes a element that’s built-in into the SoC chip. An off-SoC element is exterior to the SoC chip.

Audio subsystem overview

Along with the SoC perform blocks that do offloaded audio processing, every related standby platform consists of an off-SoC element, known as a codec, that does the next:

  • Interprets decoded digital streams into analog sounds.
  • Drives built-in audio system.
  • Drives externally connected analog headphones.

Like with a digital camera subsystem, the audio subsystem options each on-SoC and off-SoC parts. Nonetheless, Home windows expects a single audio driver to handle each the on-SoC audio processing engines and the off-SoC codec. This single audio driver is liable for managing each the parts which are built-in into the SoC and the off-SoC parts that may be chosen by the system integrator. Subsequently, the system integrator ought to work intently with the SoC silicon vendor on audio subsystem integration and energy administration.

The audio {hardware} vendor should implement the audio driver as a Port Class (Portcls) miniport driver. The audio driver works along with the Portcls system driver, Portcls.sys, which is an inbox element of Home windows.

In comparison with different machine lessons, the audio subsystem is exclusive in the best way that it does energy administration when the platform is within the related standby energy state (that’s, when the display is turned off). When the platform is related standby, the system can generate audio sounds to inform the person of occasions (for instance, the arrival of a brand new e mail) in actual time. Moreover, the person can flip off the system show after which proceed to take heed to audio being performed by an software. These capabilities can’t be achieved by a easy energy administration technique wherein the audio subsystem have to be turned off when the system is in related standby. As an alternative, energy administration of the audio subsystem have to be carried out on a run-time idle foundation (in order that it activates solely when required) always besides when the system is within the ACPI Shutdown (S5) state.

The audio driver performs run-time idle energy administration in shut cooperation with the Home windows audio infrastructure and the PortCls system driver. PortCls displays any accesses (equivalent to I/O and property accesses) of the audio machine and resets the idle timer on every entry. If the idle timer expires, PortCls transitions the audio machine (with assist from the audio driver) to a low-power sleep (D3) state. PortCls returns the audio machine to the lively (D0) state within the occasion of latest entry exercise.

PortCls additionally registers with the Home windows energy framework (PoFx) in order that the system energy engine plug-in (PEP) will be notified of audio machine energy state adjustments. These notifications enable the PEP to know when it will possibly safely flip off clocks and energy rails that may be shared between the audio processing items and different SoC perform blocks.

We advocate that when the audio subsystem shouldn’t be getting used, it must be in a sleep state wherein a complete of lower than one milliwatt is consumed by the audio subsystem. This whole consists of the facility consumed by the audio processing items, the off-SoC codec, and any further audio circuitry (for instance, amplifiers for audio system and headphones).

Audio subsystem {hardware} topology

The audio subsystem is comprised of a number of on-SoC and off-SoC parts, however is offered to Home windows as a single machine within the ACPI namespace.

The audio processing items are positioned on the SoC. SoCs from totally different distributors have audio processing items that fluctuate of their capabilities, energy consumption, and efficiency. The audio processing items carry out audio offloading—they course of audio streams (for instance, by mixing and making use of audio results) with out utilizing the principle processor. For audio playback that’s not latency delicate, offloading audio from the principle processor is most popular as a result of the audio processing items use much less energy than the principle processor.

For extra details about offloaded audio, see {Hardware}-Offloaded Audio Processing.

The system additionally consists of an off-SoC audio codec that converts the digital audio stream to analog output to drive built-in audio system or exterior headphones. The codec would possibly embody built-in analog amplifiers for audio system and headphones. Or, discrete amplifiers can be utilized as a substitute. A typical codec has the next connections to the on-SoC audio processing unit:

  • A digital audio interface (I2S or related serial bus).
  • A management interface (sometimes I2C or related serial bus).
  • A number of GPIO pins to regulate energy administration circuitry and to interrupt the SoC when the codec state adjustments.

These connections are proven within the following block diagram.

audio device

From the viewpoint of Home windows, the audio processing unit and the audio codec collectively comprise the audio machine. The audio machine have to be enumerated within the ACPI namespace as a single machine object.

Though the audio subsystem must be uncovered to Home windows by way of a single audio driver, the SoC vendor would possibly, as an possibility, undertake a driver extension mannequin wherein the audio driver is decomposed into two or extra separate drivers. For instance, the management software program that instantly manages the audio codec may be positioned in a codec driver that’s separate from the principle audio driver. The principle audio driver then not directly manages the codec by speaking with the codec driver. The small print of this driver extension mannequin are exterior the scope of this doc and are proprietary to the SoC vendor’s audio driver. The system integrator ought to work instantly with the SoC silicon vendor to implement such proprietary options within the audio subsystem.

Energy administration modes

The audio subsystem should help the next two energy administration modes:

  • An lively mode wherein audio is actively being streamed for the person.
  • A low-power sleep mode wherein the audio processing unit is turned off, the off-SoC codec is positioned in a low-power mode, and the mixed audio subsystem parts devour lower than one milliwatt.

The next desk describes these two energy modes.

Mode Description Gadget energy state (Dx) Common energy consumption Exit latency to lively Transition mechanism
Lively (streaming) The audio processing items are actively streaming audio and the codec is offering analog or digital audio to an audio endpoint equivalent to headphones, built-in audio system, or a distant HDMI output machine. D0

<= 100 milliwatts

(audio processing + codec)

N/A

Transition to D0 initiated by Portcls.

Happens when an software or system service initiates audio streaming.

Sleep The audio processing items aren’t streaming audio and the codec shouldn’t be operational aside from standby energy enough to detect jack insertion or removing. D3

<= 1 milliwatt

(Really useful.)

<= 35 milliseconds or <= 300 milliseconds, relying on system situation.

(Required.)

Transition to D3 initiated by Portcls.

Happens when all purposes end audio streaming and the driver-provided or system-provided idle time-out expires.

In some SoC designs, the audio processing items are multifunction blocks shared with video decoding and graphics processing. With these designs, there could also be situations wherein the audio processing items are powered on when audio shouldn’t be actively streaming.

Software program energy administration mechanisms

The first software program energy administration mechanism for the audio subsystem is run-time idle detection that’s constructed into PortCls. Run-time idle detection permits PortCls to look at the appliance audio streaming exercise to find out when to modify the audio machine between the lively and sleep energy modes. PortCls additionally allows a proprietary extension mechanism between the audio driver and the SoC vendor-provided energy engine plug-in (PEP) to handle the efficiency state of the audio processing items.

Run-time idle detection

The parts within the audio subsystem enter the low-power sleep mode after the audio subsystem is idle for some specified time-out interval.

The audio driver that’s offered by the SoC vendor should register the next two default idle time-out settings:

  • PerformanceIdleTime – Use this time-out interval when the {hardware} platform is plugged into AC energy.
  • ConservationIdleTime – Use this time-out interval when the platform is working on battery energy.

The idle time-out settings are saved in registry entries which are positioned below the audio driver’s PowerSettings registry key. For extra info, see Audio Gadget Class Inactivity Timer Implementation.

The next .inf directives have to be used to set a PerformanceIdleTime time-out of 1 second and a ConservationIdleTime time-out of 1 second:

[MyAudioDevice.AddReg]
HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
HKR,PowerSettings,IdlePowerState,1,03,00,00,00

PortCls collaborates with the Home windows kernel energy supervisor to routinely swap between the PerformanceIdleTime and ConservationIdleTime time-out values because the platform transitions between AC energy and battery energy.

When the system is in related standby (that’s, with the display turned off) and audio playback shouldn’t be initiated, PortCls at all times makes use of an idle time-out of 1 second, whatever the time-out setting that the adapter driver specifies in its .inf file.

The audio driver offered by the SoC vendor should additionally register an IdlePowerState setting to specify the facility state to transition to when the idle time-out expires. On all related standby platforms, audio drivers should register D3 as the facility state to enter when an idle time-out happens. To specify the D3 state, the AddReg directive within the previous instance units the IdlePowerState worth to 03.

When the idle time-out expires, PortCls calls the audio driver’s IAdapterPowerManagement3::PowerChangeState3 technique to inform the driving force to organize the audio machine to enter the low-power sleep mode (NewPowerState = PowerDeviceD3). The audio driver should save context for the audio processing unit and place the codec right into a low-power sleep mode that consumes lower than one milliwatt, on common. Within the low-power sleep mode, the codec should proceed to have enough energy to detect audio jack insertion/removing and generate a level-triggered interrupt to the principle processor on the SoC.

When audio playback is required due to software streaming, system sound technology, or auditory notification throughout related standby, PortCls calls the audio driver’s PowerChangeState3 technique to inform the driving force to configure the audio machine to function within the lively (D0) energy state (NewPowerState = PowerDeviceD0). The audio driver should restore context for the audio processing unit and re-enable the codec.

PortCls calls the audio driver’s IAdapterPowerManagement3::D3ExitLatencyChanged technique to inform the driving force of a change within the most latency that may be tolerated for transitions from the sleep (D3) state to the lively (D0) state. PortCls calls the audio driver’s D3ExitLatencyChanged technique to set the utmost latency to both 35 milliseconds or 300 milliseconds. The audio driver should respect the utmost latency tolerance and never enter a low-power state that requires a resume latency bigger than the worth specified by PortCls within the D3ExitLatencyChanged technique.

Codec energy administration

The audio driver that’s offered by the SoC vendor can be liable for configuring and power-managing the off-SoC audio codec. The motive force sometimes controls the audio codec by way of an I²C or different easy peripheral bus (SPB) connection from the SoC. The motive force should additionally deal with interrupts from the codec machine.

The audio driver should transition the codec to a low-power sleep mode when the audio subsystem enters the D3 (sleep) state.

The audio driver should transition the codec to the lively energy mode when the audio subsystem enters the D0 (lively) state.

Home windows energy framework (PoFx) and the facility engine plug-in (PEP)

PortCls registers with the Windowspower administration framework in order that the SoC-vendor-provided PEP is notified of audio machine transitions between the lively (D0) and sleep (D3) energy modes. In lots of SoC designs, the clock and energy rails for the audio processing items are shared with different on-SoC purposeful blocks. The PEP offered by the SoC vendor is conscious of the SoC-specific clock and energy topologies and takes the suitable motion to cease clocks or to show off energy rails related to the audio processing unit when it’s within the sleep mode.

Moreover, PortCls helps a personal mechanism known as context sharing that enables the audio driver to speak instantly with the PEP to carry out fine-grained energy administration. For instance, an audio driver can use context sharing to tell the PEP of the present audio stream content material sort and bit price. The PEP makes use of this info to scale the clock frequency for the audio processing unit all the way down to the minimal that’s required to course of the present audio stream with out glitching.

The context sharing interface is outlined as a easy enter/output buffer with a GUID identifier, and is much like different extensible Home windows energy administration interfaces. For extra details about context sharing between the miniport driver and the PEP, see PortCls Non-public PEP Context Sharing.

Supported {hardware} energy configuration

In related standby platforms, Home windows helps a single {hardware} energy administration configuration for the audio subsystem.

Within the anticipated configuration, the audio processing items are positioned on the SoC, and the exterior audio codec is related to the SoC by way of a SoC-compatible digital audio interface, a easy peripheral bus (SPB) equivalent to I²C, and a number of GPIO pins. We advocate that the audio codec and exterior logic devour no a couple of milliwatt within the sleep energy mode.

The next block diagram exhibits the anticipated {hardware} configuration, the Audio machine driver stack, and the user-mode parts.

audio stack

The audio subsystem can have parts positioned behind the codec that aren’t seen to the working system and its drivers. For instance, these parts would possibly embody amplifiers for the audio system and headphones. Such parts are platform-specific and will be chosen by the system integrator throughout the necessities outlined as a part of the Home windows Certification program.

The system integrator should enumerate the SoC audio machine within the root of the APCI namespace hierarchy. All reminiscence, I/O, GPIO, and I²C (or different SPB) sources required for the audio processing unit and the exterior codec have to be listed within the _CRS object below the machine within the namespace. The system integrator and ACPI firmware developer should talk with the audio driver developer to know the conventions for ordering {hardware} sources, equivalent to GPIO pins. For instance, a driver that receives two GPIO sources distinguishes between them primarily based on the order wherein they seem within the useful resource checklist. For extra info, see GPIO-Based mostly {Hardware} Sources.

Though the ACPI driver (Acpi.sys) can observe the lively (D0) and sleep (D3) transitions because the machine energy IRPs circulation by way of the audio stack, the system integrator should not describe the audio codec as a part of an influence useful resource or use the _PS0 and _PS3 ACPI management strategies to alter the codec energy state. In sleep mode, the codec is anticipated to function at sufficiently low energy that it may be left on always to detect jack insertion and removing.

The audio codec and any exterior amplifiers have to be positioned on an influence rail that’s at all times powered on besides when the system is within the ACPI Shutdown (S5) state. GPIO pins can be utilized to allow or disable the amplifiers on demand. The amplifiers will be managed by utilizing GPIO pins from both the codec or the SoC.

A key requirement is that the codec itself stays powered always—even when it is in a low-power sleep mode—in order that jack insertion and removing will be detected. The codec should generate an interrupt that may wake the SoC from its deepest idle state to deal with headphone jack insertion and removing.

Wake considerations (headphone and microphone jack detection)

The audio subsystem should deal with adjustments within the state of the audio output machine that may happen at any time. The commonest audio machine state adjustments are the insertion of an output machine into the built-in headphone jack and the removing of this machine from the jack. Jack insertion and removing should even be detected for another connected audio ports, together with microphone and digital sign ports.

Always, the audio stack should be capable to detect jack insertion and removing. The interrupt line from the audio codec have to be related to a GPIO pin that’s at all times powered and at all times able to waking the SoC from its deepest idle state. Jack detection allows Home windows to take care of up-to-date details about the audio enter and output gadgets in real-time, together with all instances when the system is in related standby. For instance, Home windows is straight away notified when the person inserts a plug into the headphones jack. In response to this notification, any future related standby notification alert sounds are routed to the headphones as a substitute of to the platform’s built-in audio system.

As beforehand described, the system firmware assigns a set of {hardware} sources to the audio machine. These sources are described within the ACPI _CRS object, and the working system passes a listing of those sources to the audio driver. This useful resource checklist consists of all GPIO interrupts which are used to detect state adjustments within the audio output machine (for instance, headphone insertion). These interrupts have to be marked within the system ACPI firmware as wake sources. The audio driver is anticipated so as to add interrupt handlers for every of those wake interrupts. The interrupt handlers should replace the state of the audio machine, the audio codec, and the audio driver, as applicable, primarily based on which interrupt was signaled.

The ordering of sources within the _CRS object relies on a device-specific conference that’s outlined by the audio driver developer. For instance, if the driving force receives two interrupt sources, the driving force distinguishes between them primarily based on the order wherein they happen within the useful resource checklist. The ACPI firmware developer should use the identical ordering to explain these sources within the ACPI firmware.

A number of {hardware}, firmware, and software program subsystems should collaborate to make audio jack insertion and removing detection work appropriately. The system integrator and audio driver developer should adhere to the next implementation tips:

{Hardware} and SoC

  • The audio codec {hardware} should detect headphone, microphone, and different jack insertion and removing occasions always that the system is powered on, together with when the system is in related standby.
  • The audio codec {hardware} should be capable to detect jack insertion and removing whereas consuming little or no energy (lower than one milliwatt common).
  • The audio codec interrupt have to be related to a GPIO pin on the SoC that’s able to waking the SoC from its deepest energy state.

ACPI firmware

  • The audio machine have to be described within the ACPI namespace.
  • The GPIO traces used to detect jack insertion have to be described by the ACPI firmware as unique and wake interrupts. Use the GpioInt descriptor macro and set the Shared argument to ExclusiveAndWake.
  • The audio machine’s {hardware} sources have to be listed within the order that’s anticipated by the audio driver.

Audio driver software program

  • The audio driver should join an interrupt handler to the GPIO wake interrupts.
  • When the audio driver handles the interrupt, it evaluates the state of the audio enter/output gadgets and performs the suitable actions.

Testing and validation

System integrators can use the Home windows Efficiency Analyzer (WPA) to confirm that the audio machine appropriately performs run-time idle energy administration and transitions as anticipated between the lively (D0) and sleep (D3) states. WPA is accessible on the Microsoft Join web site. Please contact your Microsoft consultant for help in acquiring WPA and the WPA Energy Administration extensions. The system integrator must also receive the WPA Energy Administration Evaluation Instruments package deal. This package deal consists of extensions to WPA that allow system energy administration evaluation.

WPA depends on Occasion Tracing for Home windows (ETW) instrumentation that’s constructed into the Home windows kernel and different Home windows parts, together with PortCls. To make use of ETW tracing, a set of hint suppliers are enabled, and their occasions are recorded right into a log file whereas a take a look at situation runs. When the situation finishes, the hint suppliers are stopped. WPA allows post-processing and visible evaluation of the log file that’s generated by the situation below take a look at.

On a system that has WPA put in, a set of instructions can be utilized to gather energy administration instrumentation to validate the facility administration of the audio machine. The Xperf.exe instrument is put in within the %Program FilespercentWindows Kits8.0Windows Efficiency Analyzer folder.

To start out energy administration ETW tracing, open a Command Immediate window as Administrator, change to the listing that incorporates WPA, and run the next instructions:

>xperf -start powertracesession -on Microsoft-Home windows-Kernel-Energy
>xperf -capturestate powertracesession Microsoft-Home windows-Kernel-Energy

These instructions instruct Home windows to allow the Microsoft-Home windows-Kernel-Energy ETW occasion supplier and to seize the preliminary state of occasions from the Microsoft-Home windows-Kernel-Energy supplier.

After the ETW tracing has began, the developer ought to train system situations to confirm that the audio machine appropriately transitions between the lively (D0) and sleep (D3) energy modes. The developer ought to validate audio machine within the following situations:

  • Launch an software that transitions the audio machine from the D3 state to the D0 state.
  • One second in any case audio purposes are closed, the audio machine transitions to D3 from the D0 state.
  • When the system is in related standby, the audio machine stays within the D3 state.
  • When an auditory notification is generated throughout related standby, the audio machine transitions from D3 to D0, performs audio, after which returns to D3 after one second.

After these take a look at situations have accomplished, use the next command cease ETW hint assortment:

>xperf -stop powertracesession -d hint.etl

Use WPA to open the ensuing Hint.etl file. To launch WPA from the command line, enter the command Wpa.exe.

Within the WPA instrument, choose the Gadget Dstate graph from the Graph Explorer checklist, and the next view ought to seem.

device d-state graph from the graph explorer list

On this view, a tool is recognized both by its ACPI identify (for instance, _SB.AUDI) or the machine occasion path (for instance, ACPIMSFT07314%ffff367&2). Each the ACPI identify and the machine occasion path are listed within the abstract desk for the Gadget Dstate graph.

To view the D-state transitions made by the audio machine, discover the machine identify within the abstract desk, right-click on the identify, and select Filter to Choice. The ensuing graph exhibits the D-state transitions of the audio machine solely, as proven within the following screenshot.

d-state transitions

This instance hint exhibits that the audio machine was within the D3 state (indicated by coordinate 3 on vertical axis) for the whole hint period aside from one five-second interval at roughly 290 seconds from the beginning of the hint.

Energy administration guidelines

System integrators and SoC distributors ought to use the next guidelines to make sure that their audio subsystem energy administration design is suitable with Home windows 8.1.

  • The system integrator ought to work intently with the SoC vendor to combine audio subsystem gadgets.

  • The audio driver developed by the SoC vendor should do the next:

    • Set run-time idle time-outs for when the system is working on AC energy and on battery energy. The audio driver should set each the PerformanceIdleTime worth and ConservationIdleTime worth to 1 second.

    • Set the IdlePowerState worth to D3.

    • Within the .inf file for the audio driver, set IdlePowerState, PerformanceIdleTime, and ConservationIdleTime to the next values:

      [MyAudioDevice.AddReg]
      HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
      HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
      HKR,PowerSettings,IdlePowerState,1,03,00,00,00
      
    • The audio driver should save all audio processing unit context and place the codec right into a low-power sleep mode when PortCls calls the driving force’s IAdapterPowerManagement3::PowerChangeState3 technique with a tool energy state of D3.

    • The audio driver should restore all audio processing unit context and re-enable the codec when PortCls calls the driving force’s PowerChangeState3 technique with a tool energy state of D0.

    • The audio driver should not use energy states that violate the D3 exit latency requirement offered by PortCls within the IAdapterPowerManagement3:D3ExitLatencyChanged technique.

    • The audio driver should deal with configuration and energy administration of the exterior codec.

    • The audio driver should deal with level-triggered interrupts from the exterior codec when the codec detects jack insertion or removing.

  • The SoC vendor should present an influence engine plug-in (PEP) that does the next:

    • Places the audio processing items in a low-power state when the audio driver transitions to the sleep (D3) mode.
    • Activates any clock and energy rails wanted for the audio processing items when the audio driver transitions to the lively (D0) energy mode.
    • Appropriately scales the clock and voltage provided to the audio processing unit in line with the required degree of processing exercise, which is determined by the audio format, content material sort, and bit price.
  • To develop the {hardware} and firmware platform for the audio subsystem, the system integrator should do the next:

    • Use a codec that, in sleep mode, consumes lower than one milliwatt however can nonetheless detect jack insertion and removing occasions.
    • Place the codec on a system energy rail that’s turned on always, besides when the system is within the ACPI Shutdown (S5) state.
    • Design the ACPI firmware to enumerate the audio subsystem as a single machine within the root of the ACPI namespace hierarchy.
    • Decide the reminiscence, interrupt, I/O, GPIO, and I²C resource-ordering conventions anticipated by the audio driver and be certain that the sources are listed in the identical order within the ACPI _CRS object.
  • To check and validate the facility administration of the audio subsystem, the system integrator should do the next:

    • Confirm that the audio driver transitions to the D3 energy state when no purposes are utilizing the audio subsystem or producing audio for the person.
    • Confirm that the audio driver transitions to the lively (D0) energy state when an software or the system is producing audio, together with throughout audio playback when the display is turned off.
    • Confirm that audio playback is carried out in a glitch-free and error-free method utilizing the exams offered within the Home windows Certification Take a look at Suite (HCK).
    • Be sure that jack detection works appropriately when the system is in related standby, and that audio is appropriately routed to the headphones or audio system when the person inserts the plug within the headphones jack or removes the plug from the jack.
    • Measure the facility consumed by the audio processing unit, the exterior codec, and any further analog amplification circuitry. Be sure that the whole audio subsystem consumes lower than one milliwatt when it’s within the sleep (D3) energy state.

Leave a Reply

Your email address will not be published. Required fields are marked *