Risparmio energia sottosistema audio per piattaforme di standby moderne

Ogni PC Windows ha un sottosistema audio che consente all'utente di ascoltare e registrare audio di alta qualità in tempo reale. Una piattaforma hardware che supporta il modello di alimentazione standby connesso è in genere basata su un circuito integrato System on a Chip (SoC) che include unità di elaborazione audio integrate e a basso consumo.

Le unità di elaborazione audio scaricano l'elaborazione audio dal processore principale (o dai processori) nel SoC. Poiché queste unità possono elaborare i dati audio senza usare il processore principale, l'utente può continuare ad ascoltare l'audio anche dopo che il processore principale entra in uno stato a basso consumo per risparmiare energia a batteria.

Questo video mostra come usare Windows analizzatore prestazioni (WPA) per verificare che un computer entri nello stato a basso consumo durante la riproduzione audio dello schermo (noto anche come audio a basso consumo o LPA).

L'articolo seguente illustra la gestione dell'alimentazione del sottosistema audio per le piattaforme standby connesse. Nella discussione seguente, il termine componente on-SoC descrive un componente integrato nel chip SoC. Un componente off-SoC è esterno al chip SoC.

Panoramica del sottosistema audio

Oltre ai blocchi di funzione SoC che eseguono l'elaborazione audio scaricata, ogni piattaforma standby connessa include un componente off-SoC, denominato codec, che esegue le operazioni seguenti:

• Converte i flussi digitali decodificati in suoni analogici.
• Unità altoparlanti incorporati.
• Unità collegate esternamente cuffie analogiche.

Come con un sottosistema della fotocamera, il sottosistema audio è dotato sia di componenti on-SoC che off-SoC. Tuttavia, Windows prevede un singolo driver audio per gestire sia i motori di elaborazione audio on-SoC che il codec off-SoC. Questo singolo driver audio è responsabile della gestione dei componenti integrati nel SoC e nei componenti off-SoC che possono essere selezionati dall'integratore di sistema. Pertanto, l'integratore di sistemi deve collaborare con il fornitore di processori SoC per l'integrazione del sottosistema audio e il risparmio energia.

Il fornitore dell'hardware audio deve implementare il driver audio come driver miniport (Portcls). Il driver audio funziona insieme al driver di sistema Portcls, Portcls.sys, che è un componente posta in arrivo di Windows.

Rispetto ad altre classi di dispositivi, il sottosistema audio è univoco nel modo in cui esegue il risparmio di energia quando la piattaforma si trova nello stato di alimentazione standby connesso (ovvero quando lo schermo è spento). Quando la piattaforma è connessa in standby, il sistema può generare suoni audio per notificare all'utente gli eventi (ad esempio, l'arrivo di un nuovo messaggio di posta elettronica) in tempo reale. Inoltre, l'utente può disattivare la visualizzazione del sistema e quindi continuare ad ascoltare l'audio riprodotto da un'applicazione. Queste funzionalità non possono essere ottenute tramite una semplice strategia di risparmio energia in cui il sottosistema audio deve essere disattivato quando il sistema è in standby connesso. Al contrario, la gestione dell'alimentazione del sottosistema audio deve essere eseguita su base inattiva in fase di esecuzione (in modo che venga attivata solo quando necessario) in qualsiasi momento, tranne quando il sistema si trova nello stato di arresto ACPI (S5).

Il driver audio esegue la gestione dell'alimentazione inattiva in fase di esecuzione in stretta collaborazione con l'infrastruttura audio di Windows e il driver di sistema PortCls. PortCls monitora tutti gli accessi (ad esempio i/O e gli accessi alle proprietà) del dispositivo audio e reimposta il timer inattivo per ogni accesso. Se il timer di inattività scade, PortCls passa il dispositivo audio (con aiuto dal driver audio) a uno stato di sospensione a basso consumo (D3). PortCls restituisce il dispositivo audio allo stato attivo (D0) in caso di nuova attività di accesso.

PortCls registra anche con Windows Power Framework (PoFx) in modo che il plug-in del motore di alimentazione di sistema (PEP) possa ricevere una notifica delle modifiche dello stato di alimentazione del dispositivo audio. Queste notifiche consentono al PEP di sapere quando può disattivare in modo sicuro orologi e binari di alimentazione che potrebbero essere condivisi tra le unità di elaborazione audio e altri blocchi di funzione SoC.

È consigliabile che quando il sottosistema audio non viene usato, deve trovarsi in uno stato di sospensione in cui un totale di meno di un milliwatt viene utilizzato dal sottosistema audio. Questo totale include la potenza consumata dalle unità di elaborazione audio, il codec off-SoC e qualsiasi circuito audio aggiuntivo (ad esempio amplificatori per altoparlanti e cuffie).

Topologia hardware del sottosistema audio

Il sottosistema audio è costituito da più componenti on-SoC e off-SoC, ma viene presentato a Windows come singolo dispositivo nello spazio dei nomi ACPI.

Le unità di elaborazione audio si trovano nel SoC. I soC di diversi fornitori hanno unità di elaborazione audio che variano in termini di capacità, consumo di energia e prestazioni. Le unità di elaborazione audio eseguono l'offload audio, ovvero elaborano flussi audio (ad esempio, combinando e applicando effetti audio) senza usare il processore principale. Per la riproduzione audio che non è sensibile alla latenza, l'offload dell'audio dal processore principale è preferibile perché le unità di elaborazione audio utilizzano meno potenza del processore principale.

Per altre informazioni sull'audio scaricato, vedi Elaborazione audio con offload hardware.

Il sistema include anche un codec audio off-SoC che converte il flusso audio digitale in output analogico in altoparlanti incorporati o cuffie esterne. Il codec può includere amplificatori analogici integrati per altoparlanti e cuffie. In alternativa, è possibile utilizzare amplificatori discreti. Un codec tipico ha le connessioni seguenti all'unità di elaborazione audio on-SoC:

• Interfaccia audio digitale (I2S o bus seriale simile).
• Interfaccia di controllo (in genere I2C o bus seriale simile).
• Uno o più pin GPIO per controllare i circuiti di risparmio energia e interrompere il SoC quando lo stato del codec cambia.

Queste connessioni sono illustrate nel diagramma a blocchi seguente.

Dal punto di vista di Windows, l'unità di elaborazione audio e il codec audio insieme comprendono il dispositivo audio. Il dispositivo audio deve essere enumerato nello spazio dei nomi ACPI come singolo oggetto dispositivo.

Anche se il sottosistema audio deve essere esposto a Windows tramite un singolo driver audio, il fornitore soC potrebbe, come opzione, adottare un modello di estensione del driver in cui il driver audio viene scomposto in due o più driver separati. Ad esempio, il software di controllo che gestisce direttamente il codec audio potrebbe essere inserito in un driver codec separato dal driver audio principale. Il driver audio principale gestisce quindi indirettamente il codec comunicando con il driver codec. I dettagli di questo modello di estensione driver non rientrano nell'ambito di questo documento e sono proprietari del driver audio del fornitore soC. L'integratore di sistemi deve lavorare direttamente con il fornitore del processore SoC per implementare tali funzionalità proprietarie nel sottosistema audio.

Modalità risparmio energia

Il sottosistema audio deve supportare le due modalità di risparmio energia seguenti:

• Modalità attiva in cui l'audio viene trasmesso attivamente per l'utente.
• Modalità sospensione a basso consumo in cui l'unità di elaborazione audio è disattivata, il codec off-SoC viene inserito in modalità a basso consumo e i componenti combinati del sottosistema audio utilizzano meno di un milliwatt.

Nella tabella seguente vengono descritte queste due modalità di alimentazione.

In alcuni progetti SoC, le unità di elaborazione audio sono blocchi multifunzione condivisi con la decodifica video e l'elaborazione grafica. Con queste progettazioni, potrebbero esserci scenari in cui le unità di elaborazione audio sono accese quando l'audio non è in streaming attivo.

Meccanismi di risparmio energia software

Il meccanismo principale di risparmio energia software per il sottosistema audio è il rilevamento di inattività in fase di esecuzione integrato in PortCls. Il rilevamento di inattività in fase di esecuzione consente a PortCls di osservare l'attività di streaming audio dell'applicazione per determinare quando cambiare il dispositivo audio tra le modalità di alimentazione attiva e sospensione. PortCls consente inoltre a un meccanismo di estensione proprietario tra il driver audio e il plug-in del motore di alimentazione fornito dal fornitore SoC (PEP) di gestire lo stato delle prestazioni delle unità di elaborazione audio.

Rilevamento inattiva in fase di esecuzione

I componenti nel sottosistema audio entrano nella modalità sospensione a basso consumo dopo che il sottosistema audio è inattivo per un intervallo di timeout specificato.

Il driver audio fornito dal fornitore soC deve registrare le due impostazioni di timeout di inattività predefinite seguenti:

• PerformanceIdleTime: usare questo intervallo di timeout quando la piattaforma hardware è collegata all'alimentazione AC.
• ConservationIdleTime: usare questo intervallo di timeout quando la piattaforma è in esecuzione sull'alimentazione a batteria.

Le impostazioni di timeout di inattività vengono archiviate nelle voci del Registro di sistema che si trovano sotto la chiave del Registro di sistema di PowerSettings del driver audio. Per altre informazioni, vedere Audio Device Class Inactivity Timer Implementation.For more information, see Audio Device Class Inactivity Timer Implementation.

Le direttive .inf seguenti devono essere usate per impostare un timeout performanceIdleTime di un secondo e un timeout di Un secondo per ConservationIdleTime:

[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 collabora con lo strumento di risparmio energia del kernel windows per passare automaticamente tra i valori di timeout PerformanceIdleTime e ConservationIdleTime durante la transizione della piattaforma tra alimentazione AC e alimentazione della batteria.

Quando il sistema è in standby connesso (ovvero con lo schermo spento) e la riproduzione audio non viene avviata, PortCls usa sempre un timeout di inattività di un secondo, indipendentemente dall'impostazione di timeout specificata dal driver dell'adattatore nel file inf.

Il driver audio fornito dal fornitore soC deve anche registrare un'impostazione IdlePowerState per specificare lo stato di alimentazione da passare a quando scade il timeout di inattività. In tutte le piattaforme standby connesse, i driver audio devono registrare D3 come stato di alimentazione per entrare quando si verifica un timeout di inattività. Per specificare lo stato D3, la direttiva AddReg nell'esempio precedente imposta il valore IdlePowerState su 03.

Quando scade il timeout di inattività, PortCls chiama il metodo IAdapterPowerManagement3::P owerChangeState3 del driver per indicare al driver di preparare il dispositivo audio per accedere alla modalità sospensione a basso consumo (NewPowerState = PowerDeviceD3). Il driver audio deve salvare il contesto per l'unità di elaborazione audio e posizionare il codec in una modalità di sospensione a basso consumo che consuma meno di un milliwatt, in media. Nella modalità sospensione a basso consumo, il codec deve continuare ad avere una potenza sufficiente per rilevare l'inserimento/rimozione del jack audio e generare un interrupt attivato dal livello al processore principale nel SoC.

Quando la riproduzione audio è necessaria a causa del flusso dell'applicazione, della generazione audio del sistema o della notifica uditiva durante la standby connessa, PortCls chiama il metodo PowerChangeState3 del driver audio per indicare al driver di configurare il dispositivo audio in modo che funzioni nello stato di alimentazione attivo (D0) (NewPowerState = PowerDeviceD0). Il driver audio deve ripristinare il contesto per l'unità di elaborazione audio e riabilitare il codec.

PortCls chiama il metodo IAdapterPowerManagement3::D 3ExitLatencyChanged del driver per notificare al driver una modifica della latenza massima che può essere tollerata per le transizioni dallo stato di sospensione (D3) allo stato attivo (D0). PortCls chiama il metodo D3ExitLatencyChanged del driver audio per impostare la latenza massima su 35 millisecondi o 300 millisecondi. Il driver audio deve rispettare la tolleranza di latenza massima e non immettere uno stato a basso consumo che richiede una latenza di ripresa maggiore del valore specificato da PortCls nel metodo D3ExitLatencyChanged .

Codec risparmio energia

Il driver audio fornito dal fornitore soC è anche responsabile della configurazione e della gestione dell'alimentazione del codec audio off-SoC. Il driver controlla in genere il codec audio tramite una connessione I²C o un altro bus periferico semplice (SPB) dal SoC. Il driver deve anche gestire gli interrupt dal dispositivo codec.

Il driver audio deve eseguire la transizione del codec a una modalità sospensione a basso consumo quando il sottosistema audio entra nello stato D3 (sospensione).

Il driver audio deve eseguire la transizione del codec alla modalità di alimentazione attiva quando il sottosistema audio entra nello stato D0 (attivo).

Windows Power Framework (PoFx) e il plug-in del motore di alimentazione (PEP)

PortCls si registra con il framework di risparmio energia windowsin modo che il pep fornito dal fornitore SoC riceve una notifica delle transizioni di dispositivo audio tra le modalità di alimentazione attive (D0) e sospensione (D3). In molti progetti SoC, l'orologio e le guide di alimentazione per le unità di elaborazione audio sono condivisi con altri blocchi funzionali on-SoC. Il PEP fornito dal fornitore SoC è a conoscenza delle topologie di clock e alimentazione specifiche di SoC e esegue l'azione appropriata per arrestare gli orologi o disattivare le guide di alimentazione associate all'unità di elaborazione audio quando è in modalità sospensione.

Inoltre, PortCls supporta un meccanismo privato denominato condivisione del contesto che consente al driver audio di comunicare direttamente con il PEP per eseguire il risparmio energia con granularità fine. Ad esempio, un driver audio può usare la condivisione del contesto per informare il PEP del tipo di contenuto del flusso audio corrente e della velocità di bit. Il PEP usa queste informazioni per ridimensionare la frequenza di clock per l'unità di elaborazione audio fino al minimo necessario per elaborare il flusso audio corrente senza glitch.

L'interfaccia di condivisione del contesto è definita come un buffer di input/output semplice con un identificatore GUID ed è simile ad altre interfacce di risparmio energia di Windows estendibili. Per altre informazioni sulla condivisione del contesto tra il driver miniport e il PEP, vedere PortCls Private PEP Context Sharing.For more information about context sharing between the miniport driver and the PEP driver, see PortCls Private PEP Context Sharing.

Configurazione dell'alimentazione hardware supportata

Nelle piattaforme standby connesse Windows supporta una singola configurazione di risparmio energia hardware per il sottosistema audio.

Nella configurazione prevista, le unità di elaborazione audio si trovano sul SoC e il codec audio esterno è connesso al SoC tramite un'interfaccia audio digitale compatibile con SoC, un bus di periferiche semplice (SPB) come I²C e uno o più pin GPIO. È consigliabile utilizzare il codec audio e la logica esterna non più di un milliwatt nella modalità di alimentazione sospensione.

Il diagramma a blocchi seguente mostra la configurazione hardware prevista, lo stack di driver di dispositivo audio e i componenti in modalità utente.

Il sottosistema audio può avere componenti che si trovano dietro il codec che non sono visibili al sistema operativo e ai relativi driver. Ad esempio, questi componenti possono includere amplificatori per gli altoparlanti e le cuffie. Tali componenti sono specifici della piattaforma e possono essere selezionati dall'integratore di sistema entro i requisiti descritti come parte del programma di certificazione Windows.

L'integratore di sistema deve enumerare il dispositivo audio SoC nella radice della gerarchia dello spazio dei nomi APCI. Tutte le risorse di memoria, I/O, GPIO e I²C (o altre risorse SPB) necessarie per l'unità di elaborazione audio e il codec esterno deve essere elencato nell'oggetto _CRS nello spazio dei nomi del dispositivo. L'integratore di sistema e lo sviluppatore di firmware ACPI devono comunicare con lo sviluppatore di driver audio per comprendere le convenzioni per l'ordinamento delle risorse hardware, ad esempio i pin GPIO. Ad esempio, un driver che riceve due risorse GPIO distingue tra di esse in base all'ordine in cui vengono visualizzate nell'elenco di risorse. Per altre informazioni, vedere Risorse hardware basate su GPIO.

Anche se il driver ACPI (Acpi.sys) può osservare le transizioni attive (D0) e sospensione (D3) durante il flusso degli IRP di alimentazione del dispositivo attraverso lo stack audio, l'integratore di sistema non deve descrivere il codec audio come parte di una risorsa di alimentazione o usare i metodi di controllo _PS0 e _PS3 ACPI per modificare lo stato di alimentazione del codec. In modalità sospensione, è previsto che il codec funzioni a potenza sufficientemente bassa che può essere lasciato in qualsiasi momento per rilevare l'inserimento e la rimozione del jack.

Il codec audio e gli amplificatori esterni devono essere posizionati su un binario di alimentazione sempre acceso, tranne quando il sistema si trova nello stato ACPI Shutdown (S5). I pin GPIO possono essere utilizzati per abilitare o disabilitare gli amplificatori su richiesta. Gli amplificatori possono essere controllati utilizzando pin GPIO dal codec o dal SoC.

Un requisito fondamentale è che il codec stesso rimane sempre alimentato, anche quando è in modalità sospensione a basso consumo, in modo che sia possibile rilevare l'inserimento e la rimozione del jack. Il codec deve generare un interrupt in grado di riattivare il SoC dal suo stato di inattività più profondo per gestire l'inserimento e la rimozione del jack delle cuffie.

Problemi di riattivazione (rilevamento delle cuffie e del microfono)

Il sottosistema audio deve gestire le modifiche nello stato del dispositivo di output audio che può verificarsi in qualsiasi momento. Le modifiche più comuni dello stato del dispositivo audio sono l'inserimento di un dispositivo di output nel jack delle cuffie incorporato e la rimozione di questo dispositivo dal jack. È necessario rilevare anche l'inserimento e la rimozione di jack per qualsiasi altra porta audio collegata, tra cui porte di segnale digitale e microfono.

In ogni momento, lo stack audio deve essere in grado di rilevare l'inserimento e la rimozione del jack. La linea di interrupt dal codec audio deve essere connessa a un pin GPIO sempre alimentato e sempre in grado di svegliare il SoC dal suo stato di inattività più profondo. Il rilevamento jack consente a Windows di mantenere informazioni aggiornate sui dispositivi di input audio e output in tempo reale, inclusi tutti i casi in cui il sistema è in standby connesso. Ad esempio, Windows riceve immediatamente una notifica quando l'utente inserisce una spina nel jack delle cuffie. In risposta a questa notifica, qualsiasi avviso di notifica standby connesso futuro viene instradato alle cuffie anziché agli altoparlanti predefiniti della piattaforma.

Come descritto in precedenza, il firmware di sistema assegna un set di risorse hardware al dispositivo audio. Queste risorse sono descritte nell'oggetto ACPI _CRS e il sistema operativo passa un elenco di queste risorse al driver audio. Questo elenco di risorse include tutti gli interrupt GPIO usati per rilevare le modifiche dello stato nel dispositivo di output audio (ad esempio, l'inserimento delle cuffie). Questi interrupt devono essere contrassegnati nel firmware ACPI di sistema come origini di riattivazione. È previsto che il driver audio aggiunga gestori di interrupt per ognuna di queste interruzioni di riattivazione. I gestori di interrupt devono aggiornare lo stato del dispositivo audio, del codec audio e del driver audio, in base all'interruzione segnalata.

L'ordinamento delle risorse nell'oggetto _CRS si basa su una convenzione specifica del dispositivo definita dallo sviluppatore di driver audio. Ad esempio, se il driver riceve due risorse di interrupt, il driver distingue tra di esse in base all'ordine in cui si verificano nell'elenco di risorse. Lo sviluppatore del firmware ACPI deve usare lo stesso ordine per descrivere queste risorse nel firmware ACPI.

Più sottosistemi hardware, firmware e software devono collaborare per eseguire correttamente il rilevamento del jack audio e della rimozione. L'integratore di sistema e lo sviluppatore di driver audio devono rispettare le linee guida di implementazione seguenti:

Hardware e SoC

• L'hardware codec audio deve rilevare le cuffie, il microfono e altri eventi di inserimento e rimozione jack in qualsiasi momento in cui il sistema è acceso, incluso quando il sistema è in standby connesso.
• L'hardware del codec audio deve essere in grado di rilevare l'inserimento e la rimozione del jack consumando una potenza molto piccola (meno di un milliwatt medio).
• L'interrupt del codec audio deve essere connesso a un pin GPIO sul SoC in grado di svegliare il SoC dal suo stato di alimentazione più profondo.

Firmware ACPI

• Il dispositivo audio deve essere descritto nello spazio dei nomi ACPI.
• Le linee GPIO usate per rilevare l'inserimento di jack devono essere descritte dal firmware ACPI come interrupt esclusivi e di riattivazione. Usare la macro descrittore GpioInt e impostare l'argomento Shared su ExclusiveAndWake.
• Le risorse hardware del dispositivo audio devono essere elencate nell'ordine previsto dal driver audio.

Software driver audio

• Il driver audio deve connettere un gestore interrupt agli interrupt GPIO.
• Quando il driver audio gestisce l'interrupt, valuta lo stato dei dispositivi di input/output audio ed esegue le azioni appropriate.

Test e convalida

Gli integratori di sistemi possono usare windows analizzatore prestazioni (WPA) per verificare che il dispositivo audio esegua correttamente il risparmio di energia inattivo e le transizioni come previsto tra gli stati attivi (D0) e sospensione (D3). WPA è disponibile nel sito Web microsoft Connect. Contattare il rappresentante Microsoft per ricevere assistenza per ottenere WPA e le estensioni di Gestione energia WPA. L'integratore di sistemi deve anche ottenere il pacchetto WPA Power Management Analysis Tools. Questo pacchetto include estensioni a WPA che abilitano l'analisi del risparmio energia del sistema.

WPA si basa sulla strumentazione ETW (Event Tracing for Windows ) integrata nel kernel di Windows e in altri componenti di Windows, inclusi PortCls. Per usare la traccia ETW, viene abilitato un set di provider di traccia e i relativi eventi vengono registrati in un file di log durante l'esecuzione di uno scenario di test. Al termine dello scenario, i provider di traccia vengono arrestati. WPA abilita la post-elaborazione e l'analisi visiva del file di log generato dallo scenario sottoposto a test.

In un sistema in cui è installato WPA, è possibile usare un set di comandi per raccogliere la strumentazione per il risparmio energia per convalidare il risparmio energia del dispositivo audio. Lo strumento Xperf.exe viene installato nella cartella \%Programmi%\Windows Kits\8.0\Windows analizzatore prestazioni.

Per avviare la traccia ETW per il risparmio energia, aprire una finestra del prompt dei comandi come amministratore, passare alla directory che contiene WPA ed eseguire i comandi seguenti:

>xperf -start powertracesession -on Microsoft-Windows-Kernel-Power
>xperf -capturestate powertracesession Microsoft-Windows-Kernel-Power

Questi comandi indicano a Windows di abilitare il provider di eventi Microsoft-Windows-Kernel-Power ETW e di acquisire lo stato iniziale degli eventi dal provider Microsoft-Windows-Kernel-Power.

Dopo l'avvio della traccia ETW, lo sviluppatore dovrebbe esercitare scenari di sistema per verificare che il dispositivo audio passi correttamente tra le modalità di alimentazione attive (D0) e sospensione (D3). Lo sviluppatore deve convalidare il dispositivo audio negli scenari seguenti:

• Avviare un'applicazione che esegue la transizione del dispositivo audio dallo stato D3 allo stato D0.
• Un secondo dopo la chiusura di tutte le applicazioni audio, il dispositivo audio passa a D3 dallo stato D0.
• Quando il sistema è in standby connesso, il dispositivo audio rimane nello stato D3.
• Quando viene generata una notifica uditiva durante lo standby connesso, il dispositivo audio passa da D3 a D0, riproduce l'audio e quindi torna a D3 dopo un secondo.

Al termine di questi scenari di test, usare il comando seguente per arrestare la raccolta di tracce ETW:

>xperf -stop powertracesession -d trace.etl

Usare WPA per aprire il file Trace.etl risultante. Per avviare WPA dalla riga di comando, immettere il comando Wpa.exe.

Nello strumento WPA selezionare il grafico Device Dstate nell'elenco Graph Explorer e dovrebbe essere visualizzata la visualizzazione seguente.

In questa visualizzazione un dispositivo viene identificato dal nome ACPI, ad esempio \_SB. AUDI) o il percorso dell'istanza del dispositivo (ad esempio ACPI\MSFT0731\4%ffff367&2). Sia il nome ACPI che il percorso dell'istanza del dispositivo sono elencati nella tabella di riepilogo per il grafico Device Dstate .

Per visualizzare le transizioni di stato D effettuate dal dispositivo audio, trovare il nome del dispositivo nella tabella di riepilogo, fare clic con il pulsante destro del mouse sul nome e scegliere Filtra su Selezione. Il grafico risultante mostra solo le transizioni di stato D del dispositivo audio, come illustrato nello screenshot seguente.

Questa traccia di esempio mostra che il dispositivo audio era nello stato D3 (indicato dalla coordinata 3 sull'asse verticale) per l'intera durata della traccia, ad eccezione di un periodo di cinque secondi a circa 290 secondi dall'inizio della traccia.

Elenco di controllo per il risparmio energia

Gli integratori di sistemi e i fornitori soC devono usare l'elenco di controllo seguente per assicurarsi che la progettazione del risparmio energia del sottosistema audio sia compatibile con Windows 8.1.

• L'integratore di sistemi deve collaborare con il fornitore soC per integrare i dispositivi del sottosistema audio.

• Il driver audio sviluppato dal fornitore SoC deve eseguire le operazioni seguenti:

  • Impostare timeout di inattività in fase di esecuzione per quando il sistema è in esecuzione sull'alimentazione AC e sull'alimentazione a batteria. Il driver audio deve impostare sia il valore PerformanceIdleTime che il valore ConservationIdleTime su un secondo.

  • Impostare il valore IdlePowerState su D3.

  • Nel file inf per il driver audio impostare IdlePowerState, PerformanceIdleTime e ConservationIdleTime sui valori seguenti:

    [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
    

  • Il driver audio deve salvare tutto il contesto dell'unità di elaborazione audio e posizionare il codec in modalità sospensione a basso consumo quando PortCls chiama il metodo IAdapterPowerManagement3::P owerChangeState3 del driver con uno stato di alimentazione del dispositivo D3.

  • Il driver audio deve ripristinare tutto il contesto dell'unità di elaborazione audio e riabilitare il codec quando PortCls chiama il metodo PowerChangeState3 del driver con uno stato di alimentazione del dispositivo D0.

  • Il driver audio non deve usare gli stati di alimentazione che violano il requisito di latenza di uscita D3 fornito da PortCls nel metodo IAdapterPowerManagement3:D3ExitLatencyChanged.

  • Il driver audio deve gestire la configurazione e la gestione dell'alimentazione del codec esterno.

  • Il driver audio deve gestire gli interrupt attivati dal livello dal codec esterno quando il codec rileva l'inserimento o la rimozione del jack.

• Il fornitore soC deve fornire un plug-in del motore di alimentazione (PEP) che esegue le operazioni seguenti:

  • Inserisce le unità di elaborazione audio in uno stato a basso consumo quando il driver audio passa alla modalità sospensione (D3).
  • Attiva qualsiasi orologio e binario di alimentazione necessari per le unità di elaborazione audio quando il driver audio passa alla modalità di alimentazione attiva (D0).
  • Ridimensiona correttamente l'orologio e la tensione fornita all'unità di elaborazione audio in base al livello richiesto di attività di elaborazione, che dipende dal formato audio, dal tipo di contenuto e dalla velocità di bit.

• Per sviluppare la piattaforma hardware e firmware per il sottosistema audio, l'integratore di sistemi deve eseguire le operazioni seguenti:

  • Usare un codec che, in modalità sospensione, utilizza meno di un milliwatt, ma può comunque rilevare gli eventi di inserimento e rimozione jack.
  • Posizionare il codec su una guida di alimentazione di sistema che viene attivata sempre, tranne quando il sistema si trova nello stato di arresto ACPI (S5).
  • Progettare il firmware ACPI per enumerare il sottosistema audio come singolo dispositivo nella radice della gerarchia degli spazi dei nomi ACPI.
  • Determinare le convenzioni di ordinamento delle risorse di memoria, interrupt, I/O, GPIO e I²C previste dal driver audio e assicurarsi che le risorse siano elencate nello stesso ordine nell'oggetto ACPI _CRS.

• Per testare e convalidare il risparmio energia del sottosistema audio, l'integratore di sistemi deve eseguire le operazioni seguenti:

  • Verificare che il driver audio passi allo stato di alimentazione D3 quando nessuna applicazione usa il sottosistema audio o genera audio per l'utente.
  • Quando si usa standby da inattiva, verificare che il driver audio rimanga nello stato di alimentazione D0 attivo quando un'applicazione o il sistema genera audio, incluso durante la riproduzione audio quando lo schermo è spento.
  • Quando si usa standby dalla voce explcit (pressione del pulsante di alimentazione, verificare che tutti i flussi audio siano chiusi dal sistema operativo e che il driver audio passi allo stato di alimentazione D3 quando un'applicazione o il sistema genera audio (nuovo nel sistema operativo 24H2).
  • Verificare che la riproduzione audio venga eseguita in modo senza errori e senza errori usando i test forniti in Windows Hardware Lab Kit (HLK).
  • Assicurarsi che il rilevamento jack funzioni correttamente quando il sistema è in standby connesso e che l'audio viene instradato correttamente alle cuffie o agli altoparlanti quando l'utente inserisce il plug-in delle cuffie o rimuove la spina dal jack.
  • Misurare la potenza utilizzata dall'unità di elaborazione audio, dal codec esterno e da eventuali circuiti di amplificazione analogici aggiuntivi. Assicurarsi che l'intero sottosistema audio consumi meno di un milliwatt quando si trova nello stato di alimentazione di sospensione (D3).