Device Class Power Management Reference Specification

Audio Device Class

V2.0
The Audio Device-class Power Management Specification, including any future enhancements (“Audio-class Specification”), is being provided by Microsoft to encourage the development of devices which exhibit consistent behavior in a Power-managed PC system consistent with the OnNow Design Initiative.  Microsoft grants you the right to reproduce, use and distribute the Audio-class Specification for the purpose of creating, using and distributing hardware which complies with the Audio-class Specification.  Microsoft makes no warrantee that implementations that comply with the Audio-class specification do not infringe IP rights of third parties.

Information in this document is subject to change without notice.  Companies, names and data used in examples herein are fictitious unless otherwise noted.

©  Microsoft Corporation 1996, 2000.  All rights reserved.

All trademarks are the property of their respective owners.

Table of Contents

Scope	2
General Device Power Management Considerations	2
Device Driver Model	2
Audio Device State Definitions	2
Audio Device Power State Definitions	2
Audio Device Power Conservation Policy	2
Audio Device Wake-up Events	2
Minimum Audio Device Power Capabilities	2

Revision History

Revision	Date	Comments	
0.0	3/25/96	Initial proposal for consideration	
0.8a	10/21/96	Considered proposal	
1.0	12/7/96	Comments incorporated	
2.0	10/12/00	Revisions in Version 2.0 incorporate changes in power state definitions to match Appendix A of Advanced Confirmation and Power Interface Specification (ACPI) Revision 2.0.	

Scope
	This specification defines the behavior of Audio devices as it relates to power management, and, specifically, to the four device power states defined for the OnNow Architecture. It is intended that Audio vendors and system makers will be able to design consistent power-manageable products, and that OS vendors will be able to implement an appropriate Audio power management policy based on the contents of this specification.
General Device Power Management Considerations
	In the OnNow architecture, power management of individual devices is the responsibility of a policy owner in the Operating System, generally a class-specific driver.  This policy-owner will implement a power conservation policy that is appropriate for devices in its class.  The policy will operate in conjunction with a global system power policy implemented in the operating system (i.e. is the system Working or Sleeping?). In general, the device-class power conservation policy strives to reduce power consumption while the system is Working by transitioning amongst various available power states according to device usage.  Since the policy-owner in the Operating System has very specific knowledge of when a device is in use, or potentially in use, there is no need for hardware timers or such to determine when to make these transitions.  Similarly, this level of understanding of device usage makes it possible to use fewer device power states.  Generally, intermediate states attempt to draw a compromise between latency and consumption due to the uncertainty of actual device usage.  With the increased knowledge in the OS, crisp decisions can be made about whether the device is needed at all.  With this ability to turn devices off more frequently, the benefit of having intermediate states diminishes.
The policy-owner also determines what class-specific events can cause the system to transition from Sleeping to Working, and enables this functionality based on application or user requests.  Note that the definition of the wake-up events that each class supports will influence the system’s global power policy in terms of the level of power conservation the Sleeping state can attain while still meeting wake-up latency requirements set by applications or the user.
	In the OnNow architecture, bus drivers also implement power policy for their bus class (e.g. PCI, USB, etc..).  In general, the Bus driver has responsibility for tracking the device power states of all devices on its bus, and transitioning the Bus itself to only those power states that are consistent with those of  its devices.  This means that the Bus state can be no lower than the highest state of one of it’s devices.  However, enabled wake-up events can affect this as well.  For example if a particular device is in the D2 state and set to wake-up the system, and the bus can only forward wake-up requests while in the D1 state, then the Bus must remain in the D1 state even if all devices are in a lower state.
	Device power state transitions are explicitly commanded by the driver and invoked through bus-specific mechanisms (e.g. ATA Standby command, USB Suspend, etc..).  Note that the explicit command for entering the D3 state may be the removal of power.  In some cases, bus-specific mechanisms are not available and device-specific mechanisms must be used.
	The following definitions apply to devices of all classes:

•	D0:	Device is on and running.  It is receiving full power from the system, and is delivering full functionality to the user.
•	D1:	Class-specific low-power state (defined below) in which device context may or may not be lost.  Buses in D1 cannot do anything to the bus which would force devices on that bus to loose context.
•	D2:	Class-specific low-power state (defined below) in which device context may or may not be lost.  Attains greater power savings than D1.  Buses in D2 may cause devices on that bus to loose some context (e.g. the bus reduces power supplied to the bus).  Devices in D2 must be prepared for the bus to be in D2 (or higher).
•	D3:  Device is off and not running.  Device context is lost.  Power may be removed from the device.

Device power-state transitions are typically invoked through bus-specific mechanisms (for example, ATA Standby, USB Suspend, and so on). In some cases, bus-specific mechanisms are not available and device-specific mechanisms must be used. Notice that the explicit command for entering the D3 state might be the removal of power.

Any device context lost must be restored by the device driver when returning the device to the D0 state.

Device Driver Model
Throughout this document reference is made to the audio driver and minidriver. The driver is sometimes called a class driver because this sounds very object oriented. The driver — minidriver model is an aspect of the Windows Driver Model. Under this model, the class driver is responsible for implementation of power management commands, and the minidriver effects these commands for the specific hardware. Through the plug and play mechanism, a minidriver reports the power management capabilities of the hardware to the class driver.
Audio Device State Definitions
Playing
Audio is playing.
Recording
Foreground
Normal application is recording.
Recording is considered foreground unless specifically designated low priority.
Background
Speech recognition or speech activity detection is running.
Recording may be preempted by foreground recording or playing.
Any audio recording may be designated as background. 
Full Duplex
Device is simultaneously playing and recording.
Paused
File handle is open. Only devices that are playing, foreground recording or in full duplex operation may be paused.  Background recording may not be paused. State is static and never lost. The paused state assumes that a device must transition to the resumed state rapidly. Playing or recording must be resumed within 100ms. No audio samples may be lost between the device is paused and later resumed.
Closed
No file handle is open.
Audio Device Power State Definitions
State	Status	Definition	
D0	Required	Power is on. Device is operating.	
D1	Optional	Power consumption is less than D0 state. Device must be able to transition between D0 and D1 states within 100 ms. No audio samples may be lost by entering and leaving this state.	
D2	Required	Power consumption is less than D0 state. Device must be able to transition between D0 and D2 states within 100 ms. Audio samples may be lost by entering and leaving this state.	
D3	Required	The device is completely off or drawing minimal power. For example, a stereo will be off, but a light-emitting diode (LED) may be on and the stereo may be listening to IR commands.	

If a device is in the D1 or D2 state it must resume within 100 ms. A device in the D3 state may take as long as it needs to power up. It is the responsibility of the policy owner to advertise to the system how long a device requires to power up.

All audio devices must be capable of D0, D2 and D3 states. It is desirable that an audio device be capable of D1 state. The difference between D1 and D2 is that a device capable of D1 can maintain complete state information in reduced power mode. The policy owner or other software must save all states for D2-capable devices. Some audio samples may be lost in transitioning into and out of the D2 state.

Notice that the D1 state was added to allow digital signal processor (DSP)-equipped audio hardware to exploit low-power modes in the DSP. For example, a DSP may be used to implement Dolby AC-3 Decode. When paused it stops playing audio, but the DSP may contain thousands of bytes worth of state information. If the DSP supports a low-power state, it can shut down and later resume from exactly the audio sample where it paused without losing state information.

Audio Device Power Conservation Policy
For the purpose of the following state transition policy, the following device-specific operational states are defined:
•	Playing. Audio is playing.
•	Recording: 
Foreground. Normal application is recording. Recording is considered foreground unless specifically designated low priority.
Background. Speech recognition or speech activity detection is running. Recording may be preempted by foreground recording or playing. Any audio recording may be designated as background.
•	Full Duplex. Device is simultaneously playing and recording.
•	Paused. File handle is open. Only devices that are playing, foreground recording or in full duplex operation may be paused. Background recording may not be paused. State is static and never lost. The paused state assumes that a device must transition to the resumed state rapidly. Playing or recording must be resumed within 100 ms. No audio samples may be lost between the device is paused and later resumed.
•	Closed. No file handle is open.

Present State	Next State	Cause	
D3	D0	Audio device moves from closed to open state or paused when the device receives the resume command.	
D0	D1	Audio device receives pause command. If device is D1 capable, this state is preferred. If not, the device driver will preserve context, and the device will be set to D2.	
D2/D1	D0	Audio device receives a resume command.	
D0	D2	Audio device is closed. Audio inactivity timer started.	
D2	D3	Audio inactivity timer expires.	
D0	D3	Audio device is in background record mode and receives power-down command.	
When an audio device is in the D0 state it will refuse system requests to transition to D3 state unless it is in background record mode. When an audio device is paused (D1 or D2) and it receives a request to transition to the D3 state, it will save the state of the audio device and transition to the D3 state.
Since multimedia applications often open and close audio files in rapid succession, it is recommended that an inactivity timer be employed by the policy owner to prevent needless shutdowns (D3 transitions) of the audio hardware. For example, frequent power cycling may damage audio devices powered by vacuum tubes.
Wake Events
An audio device may be a wake device. For example, a USB microphone designed for security applications might use the USB wake mechanism to signal an alarm condition.
Minimum Power Capabilities
All audio devices must be capable of D0, D2 and D3 power states. If the device is capable of maintaining context while in a low-power state it should advertise support for D1. Transitional latency for the D2 or D3 states must be less than 100 ms. There are no latency restrictions for D3 transitions, but the policy owner should advertise the amount of time required.