Управление питанием звуковой подсистемы для современных резервных платформ

Каждый компьютер с Windows имеет звуковую подсистему, которая позволяет пользователю прослушивать и записывать высококачественный звук в режиме реального времени. Аппаратная платформа, поддерживающая подключенную резервную модель питания, обычно создается вокруг интегрированного канала System on a Chip (SoC), который включает встроенные блоки обработки звука с низкой мощностью.

Блоки обработки звука выгружают звуковую обработку из основного процессора (или процессоров) на SoC. Так как эти единицы могут обрабатывать звуковые данные без использования основного процессора, пользователь может продолжать прослушивать звук даже после того, как основной процессор входит в состояние низкой мощности для экономии заряда батареи.

В этом видео показано, как использовать Windows Анализатор производительности (WPA) для проверки того, что компьютер входит в состояние низкой мощности во время воспроизведения звука с низкой мощностью (также называется низкой мощностью звука или LPA).

В следующей статье рассматривается управление питанием аудио подсистемы для подключенных резервных платформ. В следующем обсуждении термин компонента on-SoC описывает компонент, интегрированный в микросхему SoC. Компонент off-SoC является внешним для микросхемы SoC .

Обзор звуковой подсистемы

Помимо блоков функций SoC, которые выполняют разгрузку аудиообработки, каждая подключенная резервная платформа включает компонент off-SoC, называемый кодеком, который делает следующее:

• Преобразует декодированные цифровые потоки в аналоговые звуки.
• Диски со встроенными динамиками.
• Диски внешних подключенных аналоговых наушников.

Как и в подсистеме камеры, звуковая подсистема включает компоненты on-SoC и off-SoC. Тем не менее, Windows ожидает, что один звуковой драйвер управляет как подсистемами обработки звука on-SoC, так и кодеком off-SoC. Этот один звуковой драйвер отвечает за управление как компонентами, интегрированными в SoC, так и компонентами off-SoC, которые могут быть выбраны системным интегратором. Таким образом, системный интегратор должен тесно взаимодействовать с поставщиком силиконовой подсистемы SoC в интеграции аудиосистемы и управлении питанием.

Поставщик звукового оборудования должен реализовать звуковой драйвер в качестве мини-драйвера класса портов (Portcls). Звуковой драйвер работает вместе с системным драйвером Portcls, Portcls.sys, который является компонентом папки "Входящие" в Windows.

По сравнению с другими классами устройств звуковая подсистема уникальна таким образом, как она выполняет управление питанием, когда платформа находится в подключенном резервном состоянии питания (то есть при отключении экрана). Когда платформа подключена в режиме ожидания, система может создавать звуковые звуки для уведомления пользователя о событиях (например, поступлении нового сообщения электронной почты) в режиме реального времени. Кроме того, пользователь может отключить системный дисплей, а затем продолжить прослушивание звука, воспроизводимого приложением. Эти возможности невозможно достичь с помощью простой стратегии управления питанием, в которой звуковая подсистема должна быть отключена, когда система находится в режиме ожидания подключения. Вместо этого управление питанием звуковой подсистемы должно выполняться на основе простоя во время выполнения (так что оно включается только при необходимости) в любое время, за исключением случаев, когда система находится в состоянии завершения работы ACPI (S5).

Звуковой драйвер выполняет управление питанием бездействия во время выполнения в тесном сотрудничестве с звуковой инфраструктурой Windows и системным драйвером PortCls. PortCls отслеживает все доступы (например, доступ к ввода-выводам и свойствам) звукового устройства и сбрасывает таймер простоя для каждого доступа. Если срок действия таймера простоя истекает, PortCls переключает звуковое устройство (с помощью звукового драйвера) в состояние с низким питанием (D3). PortCls возвращает звуковое устройство в активное состояние (D0) в случае нового действия доступа.

PortCls также регистрируется в платформе Windows Power Framework (PoFx), чтобы подключаемый модуль питания системы (PEP) можно получать уведомления об изменениях состояния питания звукового устройства. Эти уведомления позволяют PEP знать, когда он может безопасно отключить часы и линии питания, которые могут быть совместно использоваться между единицами обработки звука и другими блоками функций SoC.

Рекомендуется, чтобы при использовании звуковой подсистемы он должен находиться в состоянии сна, в котором в общей сложности меньше одного милливатта потребляется звуковой подсистемой. Это общее число включает в себя мощность, потребляемую единицами обработки звука, кодеком off-SoC и любыми дополнительными звуковыми каналами (например, усилителями для динамиков и наушников).

Топология аппаратной подсистемы звука

Звуковая подсистема состоит из нескольких компонентов on-SoC и off-SoC, но представляется Windows как единое устройство в пространстве имен ACPI.

Единицы обработки звука находятся в SoC. SoCs от разных поставщиков имеют единицы обработки звука, которые зависят от их возможностей, потребления электроэнергии и производительности. Блоки обработки звука выполняют разгрузку звука— они обрабатывают звуковые потоки (например, путем смешивания и применения звуковых эффектов) без использования основного процессора. Для воспроизведения звука, которое не учитывает задержку, разгрузка звука из основного процессора предпочтительна, так как единицы обработки звука используют меньше мощности, чем основной процессор.

Дополнительные сведения об отключенном звуке см. в разделе "Аппаратно-выключенная обработка звука".

Система также включает в себя аудиокодек off-SoC, который преобразует цифровой аудиопоток в аналоговый выход для диска встроенных динамиков или внешних наушников. Кодек может включать интегрированные аналоговые усилители для динамиков и наушников. Кроме того, дискретные усилители можно использовать вместо этого. Типичный кодек имеет следующие подключения к единице обработки звука on-SoC:

• Цифровой звуковой интерфейс (I2S или аналогичная последовательная шина).
• Интерфейс управления (обычно I2C или аналогичная последовательная шина).
• Один или несколько закреплений GPIO для управления схемой управления питанием и прерывания SoC при изменении состояния кодека.

Эти подключения показаны на следующей блок-схеме.

С точки зрения Windows модуль обработки звука и звуковой кодек вместе составляют звуковое устройство. Звуковое устройство должно быть перечислено в пространстве имен ACPI в виде одного объекта устройства.

Хотя звуковая подсистема должна быть предоставлена Windows с помощью одного звукового драйвера, поставщик SoC может принять модель расширения драйвера, в которой звуковой драйвер разложен на два или более отдельных драйверов. Например, программное обеспечение управления, которое непосредственно управляет аудиокодеком, может быть помещено в драйвер кодека, который отделен от основного звукового драйвера. Затем основной звуковой драйвер косвенно управляет кодеком, взаимодействуя с драйвером кодека. Сведения об этой модели расширения драйверов находятся за пределами области этого документа и являются владельцем звукового драйвера поставщика SoC. Системный интегратор должен работать непосредственно с поставщиком силиконовой подсистемы SoC для реализации таких собственных функций в звуковой подсистеме.

Режимы управления питанием

Звуковая подсистема должна поддерживать следующие два режима управления питанием:

• Активный режим, в котором активно выполняется потоковая передача звука для пользователя.
• Режим сна с низкой мощностью, в котором блок обработки звука отключен, кодек off-SoC помещается в режим низкой мощности, а объединенные компоненты подсистемы звука потребляют менее одного милливатта.

В следующей таблице описаны два режима питания.

В некоторых конструкциях SoC единицы обработки звука являются многофункциональными блоками, общими для декодирования видео и обработки графики. С помощью этих конструкций могут возникнуть сценарии, в которых модули обработки звука включены при активной потоковой передаче звука.

Механизмы управления питанием программного обеспечения

Основным механизмом управления питанием программного обеспечения для звуковой подсистемы является обнаружение простоя во время выполнения, встроенное в PortCls. Обнаружение простоя во время выполнения позволяет PortCls наблюдать за действием потоковой передачи звука приложения, чтобы определить, когда переключать звуковое устройство между активными и спящий режимами питания. PortCls также обеспечивает собственный механизм расширения между звуковым драйвером и подключаемым модулем power Engine, предоставляемым поставщиком SoC, для управления состоянием производительности единиц обработки звука.

Обнаружение простоя во время выполнения

Компоненты в звуковой подсистеме вступают в режим сна с низкой мощностью после простоя звуковой подсистемы в течение определенного интервала времени ожидания.

Звуковой драйвер, предоставляемый поставщиком SoC, должен зарегистрировать следующие два параметра времени ожидания простоя по умолчанию:

• PerformanceIdleTime — используйте этот интервал времени ожидания при подключении аппаратной платформы к питания AC.
• ConservationIdleTime — используйте этот интервал времени ожидания, когда платформа работает на батарее.

Параметры времени ожидания простоя хранятся в записях реестра, расположенных в разделе реестра драйвера аудио. Дополнительные сведения см. в разделе "Реализация таймера для класса аудиоустройства бездействия".

Следующие директивы INF должны использоваться для задания времени ожидания PerformanceIdleTime в одну секунду и времени ожидания в СохранениеIdleTime из одной секунды:

[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 взаимодействует с диспетчером питания ядра Windows, чтобы автоматически переключаться между значениями времени ожидания PerformanceIdleTime и ConservationIdleTime, так как платформа переходит между питанием AC и питанием батареи.

Если система подключена в режиме ожидания (то есть при отключенном экране) и воспроизведение звука не инициируется, PortCls всегда использует время ожидания бездействия в секунду независимо от времени ожидания, указанного драйвером адаптера в inf-файле.

Звуковой драйвер, предоставленный поставщиком SoC, также должен зарегистрировать параметр IdlePowerState, чтобы указать состояние питания для перехода на время ожидания простоя. На всех подключенных резервных платформах звуковые драйверы должны зарегистрировать D3 в качестве состояния питания, чтобы ввести время ожидания простоя. Чтобы указать состояние D3, директива AddReg в предыдущем примере задает значение IdlePowerState равным 03.

Когда истекает время ожидания простоя, PortCls вызывает метод IAdapterPowerManagement3::P owerChangeState3, чтобы сообщить драйверу подготовить звуковое устройство к входу в режим сна с низким питанием (NewPowerState = PowerDeviceD3). Звуковой драйвер должен сохранить контекст для единицы обработки звука и поместить кодек в режим сна с низкой мощностью, который потребляет менее одного милливатта в среднем. В режиме спящего режима низкой мощности кодек должен продолжать иметь достаточную мощность для обнаружения вставки и удаления аудиоразъема и создания прерывания, активированного на уровне основного процессора на SoC.

Когда требуется воспроизведение звука из-за потоковой передачи приложений, системного создания звука или уведомления о прослушиваниях во время подключенного ожидания, PortCls вызывает метод PowerChangeState3 драйвера, чтобы сообщить драйверу настроить звуковое устройство для работы в активном состоянии питания (D0) (NewPowerState = PowerDeviceD0). Звуковой драйвер должен восстановить контекст для единицы обработки звука и повторно включить кодек.

PortCls вызывает метод IAdapterPowerManagement3::D 3ExitLatencyChanged, чтобы уведомить драйвер изменения в максимальной задержке, которую можно допускать для перехода из состояния спящего режима (D3) в активное (D0). PortCls вызывает метод D3ExitLatencyChanged драйвера аудио, чтобы задать максимальную задержку в 35 миллисекундах или 300 миллисекундах. Звуковой драйвер должен учитывать максимальную задержку и не вводить низкое состояние питания, которое требует задержки возобновления, превышающее значение, указанное PortCls в методе D3ExitLatencyChanged .

Управление питанием Codec

Звуковой драйвер, предоставляемый поставщиком SoC, также отвечает за настройку и управление питанием аудиокодека off-SoC. Драйвер обычно управляет звуковым кодеком через IІC или другое простое подключение к периферийной шине (SPB) из SoC. Драйвер также должен обрабатывать прерывания с устройства кодека.

Звуковой драйвер должен перенести кодек в режим спящего режима с низким питанием, когда звуковой подсистемы входит в состояние D3 (спящий режим).

Звуковой драйвер должен переключить кодек в активный режим питания, когда звуковая подсистема входит в состояние D0 (активный).

Windows Power Framework (PoFx) и подключаемый модуль подсистемы питания (PEP)

PortCls регистрируется в платформе управления питанием Windows, чтобы поставщик SoC-поставщик peP уведомлял о переходе аудиоустройств между активными (D0) и режимами питания (D3). Во многих конструкциях SoC часы и линии питания для единиц обработки звука совместно используются с другими функциональными блоками on-SoC. PEP, предоставляемый поставщиком SoC, знает о часах и топологиях питания soC и принимает соответствующие меры, чтобы остановить часы или отключить рельсы питания, связанные с звуковой единицей обработки, когда она находится в спящей режиме.

Кроме того, PortCls поддерживает частный механизм, называемый общим доступом к контексту, который позволяет звуковому драйверу напрямую взаимодействовать с PEP для точного управления питанием. Например, звуковой драйвер может использовать общий доступ к контексту для информирования PEP о текущем типе контента аудиопотока и скорости передачи данных. PEP использует эти сведения для масштабирования частоты часов для единицы обработки звука до минимального значения, необходимого для обработки текущего аудиопотока без сбоя.

Интерфейс обмена контекстом определяется как простой буфер ввода и вывода с идентификатором GUID и аналогичен другим расширяемым интерфейсам управления питанием Windows. Дополнительные сведения о совместном использовании контекста между драйвером минипорта и PEP см. в статье PortCls Private PEP Context Sharing.

Поддерживаемая конфигурация питания оборудования

На подключенных резервных платформах Windows поддерживает одну конфигурацию управления питанием для звуковой подсистемы.

В ожидаемой конфигурации единицы обработки звука находятся в SoC, а внешний аудиокодек подключен к SoC через цифровой аудиоконференции , простой периферийной шины (SPB), например IІC, и один или несколько пинов GPIO. Рекомендуется использовать аудиокодек и внешнюю логику не более одного милливатта в режиме питания сна.

На следующей схеме блоков показана ожидаемая конфигурация оборудования, стек драйверов аудиоустройств и компоненты пользовательского режима.

Подсистема звука может содержать компоненты, расположенные за кодеком, которые не видны операционной системе и его драйверам. Например, эти компоненты могут включать усилители для динамиков и наушников. Такие компоненты зависят от платформы и могут быть выбраны системным интегратором в рамках требований, описанных в рамках программы сертификации Windows.

Системный интегратор должен перечислить звуковое устройство SoC в корне иерархии пространства имен APCI. Все ресурсы памяти, ввода-вывода, GPIO и IFXC (или другие spB), необходимые для единицы обработки звука, и внешний кодек должен быть указан в объекте _CRS под устройством в пространстве имен. Разработчик системного интегратора и встроенного ПО ACPI должен взаимодействовать с разработчиком звукового драйвера, чтобы понять соглашения о заказе аппаратных ресурсов, таких как пин-коды GPIO. Например, драйвер, получающий два ресурса GPIO, различает их в зависимости от порядка, в котором они отображаются в списке ресурсов. Дополнительные сведения см. в разделе аппаратных ресурсов на основе GPIO.

Несмотря на то, что драйвер ACPI (Acpi.sys) может наблюдать за активными переходами (D0) и спящего режима (D3) в качестве потока управления питанием устройства через стек звука, системный интегратор не должен описать звуковой кодек как часть ресурса питания или использовать _PS0 и _PS3 методы управления ACPI для изменения состояния питания кодека. В спяочном режиме кодек, как ожидается, будет работать с достаточно низкой мощностью, что она может быть оставлена в любое время для обнаружения вставки и удаления джека.

Звуковой кодек и любые внешние усилители должны быть помещены на электростанцию, которая всегда включена, за исключением случаев, когда система находится в состоянии завершения работы ACPI (S5). Пин-коды GPIO можно использовать для включения или отключения усилителей по требованию. Усилители можно контролировать с помощью пин-кода GPIO из кодека или SoC.

Ключевое требование заключается в том, что сам кодек всегда работает в режиме сна с низкой мощностью, чтобы можно было обнаружить вставку и удаление джека. Кодек должен создать прерывание, которое может проснуть SoC из самого глубокого состояния простоя для обработки вставки и удаления разъема для наушников.

Проблемы пробуждения (обнаружение наушников и микрофонов)

Звуковая подсистема должна обрабатывать изменения состояния звукового устройства, которое может происходить в любое время. Наиболее распространенными изменениями состояния звукового устройства являются вставка выходного устройства в встроенный разъем для наушников и удаление этого устройства из разъема. Вставка и удаление джека также должны быть обнаружены для любых других подключенных аудиопортов, включая микрофон и цифровые порты сигнала.

В любое время звуковой стек должен иметь возможность обнаруживать вставку и удаление джека. Строка прерывания из звукового кодека должна быть подключена к пин-коде GPIO, который всегда работает и всегда способен пробуждения SoC из самого глубокого состояния простоя. Обнаружение джека позволяет Windows поддерживать актуальные сведения об устройствах ввода звука и вывода в режиме реального времени, включая все время, когда система находится в режиме ожидания подключения. Например, Windows немедленно уведомляется, когда пользователь вставляет подключаемый модуль в разъем для наушников. В ответ на это уведомление все будущие звуки оповещений о резервном подключении направляются на наушники вместо встроенных динамиков платформы.

Как описано ранее, встроенное ПО системы назначает набор аппаратных ресурсов звуковому устройству. Эти ресурсы описаны в объекте ACPI _CRS, а операционная система передает список этих ресурсов звуковому драйверу. Этот список ресурсов включает все прерывания GPIO, которые используются для обнаружения изменений состояния в звуковом устройстве (например, вставка наушников). Эти прерывания должны быть помечены в встроенном ПО СИСТЕМЫ ACPI в качестве источников пробуждения. Ожидается, что звуковой драйвер добавит обработчики прерываний для каждого из этих прерываний пробуждения. Обработчики прерываний должны обновить состояние звукового устройства, звукового кодека и звукового драйвера, в зависимости от того, какой прерываний был сигналирован.

Порядок ресурсов в объекте _CRS основан на соглашении для конкретного устройства, определенного разработчиком звукового драйвера. Например, если драйвер получает два ресурса прерывания, драйвер различает их в зависимости от порядка, в котором они происходят в списке ресурсов. Разработчик встроенного ПО ACPI должен использовать тот же порядок, чтобы описать эти ресурсы в встроенном ПО ACPI.

Для правильной работы нескольких аппаратных, встроенного ПО и программных подсистем необходимо обеспечить правильную работу при вставке и удалении звукового разъема. Системный интегратор и разработчик звуковых драйверов должны соответствовать следующим рекомендациям по реализации:

Оборудование и SoC

• Оборудование аудиокодека должно обнаруживать наушники, микрофон и другие события вставки и удаления в систему, в том числе при подключении системы в режиме ожидания.
• Оборудование аудиокодека должно иметь возможность обнаруживать вставку и удаление джека при использовании очень мало энергии (менее одного милливатта в среднем).
• Прерывание звукового кодека должно быть подключено к пин-коде GPIO на SoC, который может проснуть SoC из своего глубокого состояния питания.

ВСТРОЕННОЕ ПО ACPI

• Звуковое устройство должно быть описано в пространстве имен ACPI.
• Линии GPIO, используемые для обнаружения вставки джека, должны быть описаны встроенного ПО ACPI как эксклюзивные и пробуждающие прерывания. Используйте макрос дескриптора GpioInt и задайте для общего аргумента значение ExclusiveAndWake.
• Аппаратные ресурсы звукового устройства должны быть перечислены в том порядке, в который ожидается звуковой драйвер.

Программное обеспечение драйвера аудио

• Звуковой драйвер должен подключить обработчик прерываний к прерываниям пробуждения GPIO.
• Когда звуковой драйвер обрабатывает прерывание, он оценивает состояние звуковых и выходных устройств и выполняет соответствующие действия.

Тестирование и проверка

Системные интеграторы могут использовать Windows Анализатор производительности (WPA), чтобы убедиться, что звуковое устройство правильно выполняет управление питанием во время выполнения и переходы, как ожидалось, между активными (D0) и состояниями спящего режима (D3). WPA доступна на веб-сайте Microsoft Connect. Обратитесь к представителю Майкрософт за помощью в получении расширений WPA и WPA Power Management. Системный интегратор также должен получить пакет средств анализа power Management WPA. Этот пакет включает расширения в WPA, которые обеспечивают анализ системного управления питанием.

WPA использует инструментирование трассировки событий для Windows (ETW), встроенное в ядро Windows и другие компоненты Windows, включая PortCls. Чтобы использовать трассировку ETW, включен набор поставщиков трассировки и их события записываются в файл журнала во время выполнения тестового сценария. По завершении сценария поставщики трассировки остановлены. WPA позволяет выполнять постобработку и визуальный анализ файла журнала, созданного в тестируемом сценарии.

В установленной системе WPA набор команд можно использовать для сбора инструментирования управления питанием для проверки управления питанием звукового устройства. Средство Xperf.exe устанавливается в папку \%Program Files%\Windows Kits\8.0\Windows Анализатор производительности.

Чтобы запустить трассировку трассировки трассировки управления питанием, откройте окно командной строки от имени администратора, перейдите в каталог, содержащий WPA, и выполните следующие команды:

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

Эти команды указывают Windows включить поставщик событий Windows-Windows-Kernel-Power ETW и записать начальное состояние событий от поставщика Microsoft-Windows-Kernel-Power.

После запуска трассировки ETW разработчик должен выполнять системные сценарии, чтобы убедиться, что звуковое устройство правильно переходит между активными (D0) и режимами питания (D3). Разработчик должен проверить звуковое устройство в следующих сценариях:

• Запустите приложение, которое перемещает звуковое устройство из состояния D3 в состояние D0.
• После закрытия всех звуковых приложений звуковое устройство переходит на D3 из состояния D0.
• Когда система находится в режиме ожидания, звуковое устройство остается в состоянии D3.
• Когда во время ожидания создается уведомление о прослушивающем режиме, звуковое устройство переходит с D3 на D0, воспроизводит звук, а затем возвращается в D3 после одной секунды.

После завершения этих сценариев тестирования используйте следующую коллекцию трассировок трассировки

>xperf -stop powertracesession -d trace.etl

Используйте WPA, чтобы открыть полученный файл Trace.etl. Чтобы запустить WPA из командной строки, введите команду Wpa.exe.

В средстве WPA выберите граф Dstate устройства из списка обозревателя графов, а следующее представление должно появиться.

В этом представлении устройство определяется по имени ACPI (например, \_SB. AUDI) или путь экземпляра устройства (например, ACPI\MSFT0731\4%ffff367&2). Имя ACPI и путь экземпляра устройства перечислены в сводной таблице графа Dstate устройства.

Чтобы просмотреть переходы d-состояния, сделанные звуковым устройством, найдите имя устройства в сводной таблице, щелкните правой кнопкой мыши имя и выберите "Фильтр на выбор". На полученном графике показаны только переходы состояния D звукового устройства, как показано на следующем снимке экрана.

В этом примере трассировки показано, что звуковое устройство находилось в состоянии D3 (указанное координатой 3 на вертикальной оси) в течение всего периода трассировки, за исключением одного пяти секундного периода примерно 290 секунд с начала трассировки.

Контрольный список управления питанием

Системные интеграторы и поставщики SoC должны использовать следующий контрольный список, чтобы убедиться, что их архитектура управления питанием аудиосистемы совместима с Windows 8.1.

• Системный интегратор должен тесно сотрудничать с поставщиком SoC для интеграции устройств звуковой подсистемы.

• Звуковой драйвер, разработанный поставщиком SoC, должен выполнять следующие действия:

  • Задайте время ожидания простоя во время выполнения, если система работает на питание AC и на батарее. Звуковой драйвер должен задать значение PerformanceIdleTime и Значение ConservationIdleTime в одну секунду.

  • Задайте для значения IdlePowerState значение D3.

  • В INF-файле для звукового драйвера задайте значение IdlePowerState, PerformanceIdleTime и 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 вызывает метод IAdapterPowerManagement3::P owerChangeState3 с состоянием питания устройства D3.

  • Звуковой драйвер должен восстановить весь контекст единицы обработки звука и повторно включить кодек, когда PortCls вызывает метод PowerChangeState3 драйвера с состоянием питания устройства D0.

  • Звуковой драйвер не должен использовать состояния питания, которые нарушают требование задержки выхода D3, предоставленное PortCls в методе IAdapterPowerManagement3:D3ExitLatencyChanged .

  • Звуковой драйвер должен обрабатывать конфигурацию и управление питанием внешнего кодека.

  • Звуковой драйвер должен обрабатывать прерывания, активированные на уровне, из внешнего кодека, когда кодек обнаруживает вставку или удаление джека.

• Поставщик SoC должен предоставить подключаемый модуль питания (PEP), который выполняет следующие действия:

  • Помещает единицы обработки звука в низкое состояние питания при переходе звукового драйвера в режим спящего режима (D3).
  • Включает любые часы и рельсы питания, необходимые для единиц обработки звука, когда звуковой драйвер переходит в активный режим питания (D0).
  • Правильно масштабирует часы и напряжение, предоставленные в единицу обработки звука, в соответствии с требуемым уровнем действия обработки, который зависит от формата звука, типа контента и скорости передачи.

• Чтобы разработать платформу оборудования и встроенного ПО для звуковой подсистемы, системный интегратор должен выполнить следующие действия:

  • Используйте кодек, который в спячем режиме потребляет менее одного милливатта, но по-прежнему может обнаруживать события вставки и удаления джека.
  • Поместите кодек на системную электростанцию, которая включена в любое время, за исключением случаев, когда система находится в состоянии завершения работы ACPI (S5).
  • Создайте встроенное ПО ACPI для перечисления звуковой подсистемы в качестве одного устройства в корне иерархии пространства имен ACPI.
  • Определите соглашения о заказе ресурсов, прерываниях, ввода-выводах, GPIO и IFXC, ожидаемых звуковым драйвером, и убедитесь, что ресурсы перечислены в том же порядке в объекте ACPI _CRS.

• Чтобы проверить и проверить управление питанием звуковой подсистемы, системный интегратор должен выполнить следующие действия:

  • Убедитесь, что звуковой драйвер переходит в состояние питания D3, если приложения не используют звуковую подсистему или создают звук для пользователя.
  • При отключении в режиме ожидания убедитесь, что звуковой драйвер остается в активном состоянии питания D0, когда приложение или система создает звук, в том числе во время воспроизведения звука при отключении экрана.
  • Если в режиме ожидания от записи explcit (нажмите кнопку питания, убедитесь, что все звуковые потоки закрыты из ОС, а звуковой драйвер переходит в состояние питания D3, когда приложение или система создает звук (новое в ОС 24H2).
  • Убедитесь, что воспроизведение звука выполняется без ошибок и без ошибок, используя тесты, предоставляемые в комплекте оборудования Windows (HLK).
  • Убедитесь, что обнаружение джека работает правильно, когда система подключена в режиме ожидания, и что звук правильно направляется в наушники или динамики, когда пользователь вставляет подключаемый модуль в разъем или удаляет подключаемый модуль из разъема.
  • Измеряйте мощность, потребляемую блоком обработки звука, внешним кодеком и любым дополнительным каналом аналогового амплификации. Убедитесь, что весь звуковой подсистемы потребляет менее одного милливатта, когда он находится в состоянии питания (D3).