Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
В этом разделе содержится сводка по пакетам запросов IRP для расширений аудиоклассов (ACX).
Общие сведения о расширениях аудиоклассов ACX см. в обзоре исводке объектов ACX. Сведения о целевых объектах ACX и синхронизации см. в разделе "Целевые объекты ACX" и синхронизация драйверов.
Отправка запросов IRP
Клиент ACX указывает действие с помощью запроса драйвера (IRP). Общие сведения об IRPs см. в статье о пакетах запросов ввода-вывода и Packet-Driven ввода-вывода с помощью многократно используемых IRPs.
Клиент отправляет этот запрос в канал, пин-элемент или поток с помощью канала или дескриптора потока. Идентификатор запроса является тройным:
- set (guid),
- id/index (ulong)
- необязательное значение pin-id/node-id (ulong).
Во время создания драйвер может при необходимости связать свойства, методы и события с одним из следующих объектов:
- ПИН-код
- контур
- поток
- элемент
Каждое свойство, метод или событие определяется идентификатором и обработчиком обратного вызова. По умолчанию ACX определяет все свойства, методы и события, необходимые KS-client (уровни пользовательского режима), поэтому драйверы не должны переопределить их. Драйверы должны определять только пользовательские свойства, методы и события.
Когда ACX получает запрос IoCtrl стиля ACX/KS, он проверяет запрос и блокирует буферы вызывающего объекта в памяти. Эта проверка и блокировка буфера выполняются в предпроцессном обратном вызове WDM, который ACX регистрирует при инициализации. На этом этапе ACX добавляет собственный обратный вызов завершения к WDM IRP, прежде чем передать его обратно в WDF для нормальной обработки. Обратный вызов завершения предоставляет ACX возможность добавлять и внедрять любые обходные пути совместимости по мере необходимости.
Следующий WDF вызывает обратный вызов IRP для динамической диспетчеризации. В рамках этого вызова ACX/драйвер (необязательно) связывает очередь WDF с запросом. В этом вызове ACX находит целевой объект ACX: канал, пин-элемент, элемент канала или поток с помощью дескриптора, по которому был отправлен этот запрос, и необязательный элемент pin-id/node-id/circuit-element в запросе.
В составном звуковом устройстве возможно, что целевой объект (только для канала) может находиться в стеке, отличном от исходного запроса. Кроме того, может потребоваться выполнить запрос на несколько стеков, примером этого является состояние изменения потока.
После определения целевого объекта ACX проверяет, указывается ли для целевой цепи или объекта потока альтернативное значение для очереди обработки по умолчанию; если нет, ACX использует очередь по умолчанию, связанную с текущим дескриптором. Затем ACX/драйвер поручает WDF вставить запрос либо в указанную очередь, либо в очередь по умолчанию.
Следующий WDF вызывает обратный вызов вызываемого процесса при наличии. ACX не использует обратный вызов процесса вызывающего, так как уже заблокировал буферы в памяти в предварительном обратном вызове. Таким образом, ACX сообщает WDF, чтобы не вызывать обратный вызов в процессе после указания целевой очереди запроса.
Использование вторичной очереди
Очередь ACX по умолчанию — это очередь с управлением питанием, последовательная и без блокировки. Драйвер должен переместить любой запрос с неопределенным временем в вторичную очередь. Управляемая драйвером очередь может являться пассивной очередью с ручным управлением, где драйвер может удерживать эти запросы, пока не будет готов их выполнить позже.
Запросы на опорные мощности
ACX автоматически включает и запускает устройство перед тем как отправить запрос драйверу. Это делается неявно с помощью управляемых очередей WDF. Это создает поведение, аналогичное portcls. Иными словами, перед отправкой запроса используется опорное значение мощности.
Вызов обработчика диспетчеризации очереди
Далее WDF принимает ссылку на управление энергопитанием и вызывает обработчик отправки очереди. Очередь по умолчанию, связанная с обработчиком ACX, проверяет наличие переопределений перед процессом, а при наличии ACX вызывает обратный вызов зарегистрированного драйвера. ACX позволяет драйверу указывать переопределения на основе типа запроса (свойства, события и метода) и (необязательно) идентификаторов запросов.
Если указан обратный вызов на предварительный процесс, после выполнения ACX, запрос принадлежит драйверу. Драйвер может завершить запрос или перенаправить его обратно в ACX для нормальной отправки.
Если обратный вызов предварительного процесса не указан или драйвер возвращает запрос к ACX, ACX извлекает целевой объект ACX и находит обратный вызов объявленного свойства/ события или метода. Затем он вызывает функцию обратного вызова, передав запрос WDF и целевой объект ACX (канал/поток/элемент цепи).
Следующий ACX (или для пользовательских свойств, драйвер) выполняет запрошенное действие и завершает запрос или если запрос занимает неопределенное время, драйвер может переместить запрос в вторичную очередь. Драйвер отвечает за сериализацию и выполнение всех активных ожидающих запросов.
На этой схеме показан типичный рабочий процесс отправки запросов.
На этой схеме показан рабочий процесс отправки, когда драйвер имеет определенный препроцессный вызов ACX, хотя в конечном итоге запрос обрабатывается фреймворком ACX.
Внутренние интерфейсы схемы ACX PnP
Чтобы упростить взаимодействие между ACX Endpoint Manager (EM) и компонентами драйвера ACX (компонентами режима ядра или пользовательского режима), ACX определяет следующие внутренние интерфейсы устройств PnP:
- ACXCATEGORY_CIRCUITFACTORY
- ACXCATEGORY_CIRCUIT
Em использует интерфейс ACXCATEGORY_CIRCUITFACTORY для указания целевому устройству создать или удалить определенный канал этого типа. Этот интерфейс активен, пока подчиненное устройство может создавать цепи, в противном случае он отключен (например, удаление, внезапное удаление, остановка или удаление вручную).
Подсистема аудио использует ACXCATEGORY_CIRCUIT (которые могут быть созданы в стеке устройств, отличном от стека диспетчера каналов), для отслеживания и взаимодействия с каналом ACX. Этот интерфейс активен при создании и готовности канала к обработке команд.
Дополнительные сведения о других процессах питания и PnP см. в перечислении устройств ACX и управлении питанием ACX.
См. также
Общие сведения о расширениях аудиоклассов ACX