Состав нескольких каналов ACX
В этом разделе описывается состав нескольких каналов ACX. Общие сведения о acX и списке терминов ACX см. в обзоре расширений аудиоклассов ACX.
Как описано в сводке объектов ACX, AcxCircuit представляет частичный или полный звуковой путь для пользователя воспринимаемого звукового устройства (динамики, микрофон и т. д.). AcxCircuit имеет по крайней мере один входной пин-код и один выходной пин-код (ACXPIN), и он может агрегировать один или несколько объектов AcxElements, таких как объекты. Общие сведения см. в разделе "Каналы ACX".
Композиция канала ACX
ACX связывает каналы вместе, пока они не образуют полный звуковой путь. ACX использует звуковые привязки для соединения звуковых каналов. В то же время каждый канал ACX преобразуется в фильтр KS, эти фильтры KS затем обнаруживаются построителем аудиоконечных точек (AEB), который выполняется как служба пользовательского режима. AEB сканирует обнаруженный граф фильтра KS и создает программную конечную точку звука, представляющую подчеркивание звуковой инфраструктуры при обнаружении полного звукового пути.
На следующей схеме показаны объекты ACX, используемые ACX для обнаружения, сборки и мониторинга каналов, составляющих составную конечную точку звука.
Внимание
Обратите внимание, что только типы, отображаемые в синем виде, являются общедоступными: ACXCIRCUITTEMPLATE, ACXCOMPOSITETEMPLATE (не показан), ACXMANAGER, ACXCIRCUITFACTORY и ACXCIRCUITUIT. Все типы, отображаемые в фиолете, являются внутренними, и они перечислены здесь только для иллюстрации. Внутренние типы не гарантируют, что они остаются неизменными или доступны в разных выпусках ACX и не должны вызываться или использоваться напрямую.
Диспетчер ACX анализирует шаблоны каналов во время инициализации драйверов, когда драйверы ACX регистрируют их в диспетчере ACX. Драйверы ACX регистрируют составные шаблоны или привязки с помощью ACXCIRCUTTEMPLATES (#1).
Когда диспетчер ACX получает шаблон канала, он проверка, если это шаблон экземпляра или универсальный шаблон класса.
Для шаблонов экземпляров ACX создает ACXCOMPOSITEMANAGER (#4) для универсальных шаблонов классов, ACX создает ACXCOMPOSITEFACTORY (#2), который отвечает за создание элементов ACXCOMPOSITEMANAGER (#3) при обнаружении основного канала составного. Основные каналы — это каналы, которые предоставляют удостоверение составной конечной точке звука.
ACXCOMPOSITEMANAGER в очереди создает ACXCOMPOSITE (#5) для представления подчеркивания составной звуковой конечной точки. Составной менеджер отвечает за мониторинг любого дополнительного сегмента канала, который может возникнуть после создания или инициализации составного элемента.
ACXCOMPOSITE, в свою очередь, создает ACXCIRCUITMANAGER (#6) для каждого канала, который является частью составного. ACXCIRCUITMANAGER отвечает за создание, мониторинг и управление одним каналом (#7).
Возможно, канал будет помечен как "по запросу", в таком случае ACXCIRCUITMANAGER находит свою фабрику каналов и запрашивает новый канал для составного (#8). ACXCIRCUITFACTORY создает ACXCIRCUIT в качестве запроса (#9).
Когда обнаруживаются и активны все ACXCIRCUIT, ACXCOMPOSITE становится активным, а также указывает ACXCIRCUITMANAGERS включить интерфейсы аудио для своих каналов.
На следующей схеме последовательности показано, как два канала ACX (Канал A и B) привязаны к созданию полного звукового пути, который представлен построителем аудиоконтей (AEB) с программным звуковым устройством.
Согласование формата нескольких каналов
В этом разделе описывается согласование формата при создании конечной точки звука двумя или более каналами. Общие сведения о каналах ACX см. в статье ACX multi stack cross driver communications.
Ниспадающее закрепление моста
Закрепление моста нижнего уровня — это пин-коды, которые отправляют данные в (отрисовку) или получают данные из физического звукового устройства напрямую или косвенно. Этот тип контактов может или не связан с ними ACXMODEFORMATLISTs. Эти закрепления моста имеют тип AcxPinQualifierBridgeB или AcxPinQualifierBridgeDevice. Дополнительные сведения об ACXMODEFORMATLIST см. в заголовке acxdataformat.h.
На этой схеме и в статье используется uplevel и downlevel для описания направления потока, так как направление потока вверх или вниз зависит от того, отправляются ли пин-коды в (отрисовку) или получение данных (запись).
Снизу внизу закреплений моста без ACXMODEFORMATLIST
Драйвер может не предоставлять списки форматов режима на его закреплении нижнего уровня. Если списки форматов в режиме недоступны на закреплении моста нижнего уровня, пользователь (через панель управления звуком) или другая сущность программного обеспечения не может напрямую контролировать или указывать формат звука этого пин-кода и связанных потоков. Ниже приведены некоторые сценарии, в которых эти списки не требуются:
Каналы, доступные только для потоковой передачи, которые могут быть подключены к каналу DSP, каналу CODEC или непосредственно к звуковому устройству. Эти каналы просто перемещают данные из точки А в точку B без изменения. Эти каналы не изменяют частоту выборки данных входящих и исходящих потоков. В этом случае списки форматов режима связаны с пин-кодом uplevel.
Однопотоковые каналы без элементов, которые изменяют частоту входящих и исходящих выборок. Примером этого является канал USB-аудиоустройства. В этом сценарии списки форматов режима связаны с закреплением вверх.
Отсутствие списка форматов данных подразумевает, что формат данных потока, исходящий из этого пин-кода, совместим с одним из форматов данных, подключенных к каналу.
С помощью ACXMODEFORMATLIST
Драйвер может выбрать предоставление списков форматов режима на своих закреплениях нижнего уровня. Если списки форматов в режиме доступны на закреплении моста нижнего уровня, пользователь (с помощью панели управления звуком) или другая сущность программного обеспечения может напрямую контролировать или указывать звуковой формат этого пин-кода и связанных потоков.
Ниже приведены некоторые допустимые сценарии, в которых используются следующие списки форматов в режиме:
- Каналы DSP — обычно этот тип каналов поддерживает несколько потоков, работающих с разными скоростями выборки, эти потоки внутренне преобразуются в общую частоту выборки и смешиваются перед переходом данных к следующему каналу. Элемент управления списком форматирования данных или задает окончательную (для этого канала) частоту выборки.
При наличии списка формата данных эти форматы данных должны соответствовать образцам формата данных в пин-коде следующего канала. Обратите внимание, что не нужно соответствовать режимам, см. обсуждение режимов в разделах ниже.
Списки форматов нижнего уровня позволяют пользователю или верхнему уровню управлять форматом результирующего потока, в этом случае значение по умолчанию списка используется скорость выборки, пока не будет предпринят явное действие, чтобы изменить формат этого пин-кода.
Дополнительные сведения о списках форматов см. в заголовке acxdataformat.h.
Крепления моста вверх
Закрепление моста uplevel — это пин-коды, которые получают данные из (отрисовки) или отправляют данные в (захват) программного модуля напрямую или косвенно. Этот тип контактов должен быть связан с ними ACXMODEFORMATLISTS. Эти закрепления моста имеют тип AcxPinQualifierBridgeA.
На предыдущей схеме, показанной здесь еще раз, можно также использовать для отображения потока данных отрисовки и записи данных между пин-кодом потоковой передачи, двумя каналами и устройством.
Uplevel [Bridge] закреплений без ACXMODEFORMATLIST(s)
Пин-коды uplevel без списков формата режима не являются допустимым сочетанием, и это приводит к неправильно настроенной конечной точке. Конечная точка не отображается с точки зрения пользователя.
Uplevel [Bridge] pins with ACXMODEFORMQATLIST(s)
Пин-коды uplevel должны всегда иметь один или несколько ACXMODEFORMATLISTS. Списки форматов режима указывают все возможные частоты выборки для режима и ее частоту выборки по умолчанию. В разных режимах могут быть разные наборы выборок. Частота выборки по умолчанию — предпочтительная частота выборки для этого режима.
Режимы и каналы
Пин-коды uplevel для однопоточных каналов или многопоточных каналов могут поддерживать один или несколько списков форматов режима. Один потоковые каналы одновременно активны в одном режиме, в то время как многопоточные каналы могут работать одновременно с двумя или несколькими потоками, которые могут работать одновременно с разными режимами.
Сопоставление режима
В этом разделе приводятся краткие сведения о стандартных режимах и объясняется, почему используется сопоставление "режим".
Режим RAW: поток или канал не применяет какие-либо эффекты к потоку (за исключением возможного тома, отключения звука и ограничений безопасности, таких как защита динамиков).
Режим DEFAULT: поток или канал выполняет некоторый эффект по умолчанию.
<mode_name> mode: поток или канал применяют эффекты, относящиеся к выбранному режиму <mode_name> .
Для поддержки необработанного и/или по умолчанию режима потоковой передачи обязательно требуется потоковая передача. Это необязательно для потоковых закреплений для поддержки любого другого <mode_name> modes.
В составной конечной точке может быть возможно, чтобы канал uplevel поддерживал несколько режимов, и для каналов нижнего уровня для поддержки только RAW и/или DEFAULT.
Пример в конечной точке с двумя каналами:
Пин-код канала uplevel поддерживает режимы и связанные форматы m1{f1,f2} и m2{f3,f4}, т. е. это означает, что поток пин-кода имеет формат f1 или f2, если используется m1, или формат f3 или f4 при использовании m2. Предполагается, что канал uplevel является одним потоком.
Пин-код канала нижнего уровня поддерживает режим по умолчанию{f1,f2,f3}.
В этом случае режим потока преобразуется из <режима mode_name> в режим по умолчанию, сохраняя одинаковые показатели выборки.
m1/f1 по > умолчанию/f1
m1/f2 по > умолчанию/f2
m2/f3 по > умолчанию/f3
Недопустимая запись: m2/f4 до > None
Сопоставление режима выполняется драйвером с помощью ACX. В приведенной выше таблице последняя запись недопустима, нижнее поле канала uplevel должно удалить m2/f4 в качестве параметра для поддерживаемых форматов. Обратите внимание, что это могло произойти в обратном направлении, т. е., пин-код нижнего уровня канала может поддерживаться также f4 и f5. В этом случае поддерживается f4 по умолчанию, но значение по умолчанию f5 не было. В таком случае это пин-код нижнего уровня канала, отвечающий за отсутствие списка m?/f5 в качестве параметра из списка. Дополнительные разделы ниже объясняют этот процесс.
Форматирование переговоров
Прежде чем ACX включает аудио интерфейсы каналов, составляющих составное устройство, он гарантирует, что каналы могут согласовывать режим и форматы звуковых данных. ACX выполняет уведомление об этом канале путем вызова составного инициализации обратного вызова во всех каналах составного. Последовательность выполняется с нижнего уровня (на стороне устройства) до uplevel (системная сторона). Каналы имеют возможность обновлять их форматы на этом этапе.
Экран панели управления форматом устройства
Текущая логика панели управления звуком отображает список форматов устройства следующим образом:
- Если звуковое устройство поддерживает элемент звукового модуля, список форматов данных, отображаемых на панели управления, — это список форматов данных устройства, т. е. список форматов данных, подключенный к пин-коду нижнего уровня (который подключен к выходному пин-коду элемента звукового модуля).
- Если звуковое устройство не поддерживает элемент звукового модуля, список форматов данных, отображаемых на панели управления, — это список форматов форматов данных потоковой передачи, т. е. список форматов данных, нападающий на пин-код вверх.
Создание потока с несколькими каналами
ACX использует объекты ACXSTREA МБ RIDGE, связанные с закреплением моста вниз, для автоматического распространения запроса create-stream(s) на удаленные каналы.
Когда клиентское приложение создает поток, этот запрос сначала получается пин-адресом потоковой передачи. ACX уведомляет драйвер из-за пин-кода потоковой передачи о запросе на создание потока с помощью предоставленного обратного вызова, указанного во время создания канала. В обратном вызове драйвер создает объект ACXSTREAM, представляющий поток, а затем возвращает элемент управления обратно в ACX. Когда ACX получает обратно элемент управления, он проверка, если он должен перенаправить этот запрос на создание в следующий (вниз) канал. При необходимости драйвер может перенаправить запрос на создание в следующий канал (downlevel) перед возвратом из обратного вызова create-stream. Последний вариант позволяет драйверу выполнять любые операции после завершения операций после того, как каналы нижнего уровня имели возможность обрабатывать их запросы на создание.
ACX использует следующую логику по умолчанию для создания потока:
- Если нет нижнего мостового закрепления, все сделано.
- Если драйвер уже связывал поток с ACXSTREA МБ RIDGE вручную, все готово.
- Если на закреплении моста нижнего уровня нет ACXSTREA МБ RIDGE для указанного РЕЖИМА, завершится сбой запроса.
- ACX добавляет новый поток, созданный драйвером с извлеченным ACXSTREA МБ RIDGE.
ACXSTREA МБ RIDGE выступает в качестве нескольких и одиночных. Пока в потоке есть ACXSTREA МБ RIDGE сохраняет внепоток. Внепоток удаляется только при удалении последнего в потоке. ACXSTREA МБ RIDGE использует ACXDATAFORMATLISTS, связанные с закреплением моста вниз при выборе режима и формата, используемого для удаленного канала.
ACXSTREA МБ RIDGE использует следующую логику для выбора режима и формата данных вне потока:
Если режим для внепотока не указан, проверка, если имеется список форматов по умолчанию.
Если режим для внепотока не указан и список форматов по умолчанию отсутствует, проверка если существует список необработанных форматов.
Если режим NULL_GUID, проверка, если существует список форматов, связанный с РЕЖИМом первого в потоке.
Если задан режим, проверка, если для этого РЕЖИМА существует список форматов.
Если список форматов найден, получите формат по умолчанию из списка форматов.
Если формат не найден, ACXSTREA МБ RIDGE использует формат первого в потоке.
ACXSTREA МБ RIDGE создает поток создания запроса с помощью ACXTARGETSTREAM с помощью полученного РЕЖИМА и формата данных следующим образом:
- Если задан режим, используется этот режим.
- Если режим был NULL_GUID, используется режим первого в потоке.
- Кроме того, режим не используется.
ACX заботится об удалении и закрытии целевого потока при удалении последнего в потоке.
Еще одним заданием ACXSTREAMCIRCUIT является автоматическое распространение состояния потока вдоль цепочки потоковой передачи.
Драйвер имеет возможность отключить удаленное создание моста потока по умолчанию путем вызова AcxCircuitInitDisableDefaultStreamBridgeHandling или вручную связывания объекта ACXSTREAM с ACXSTREA МБ RIDGE перед возвратом управления в ACXX. В последнем случае удаленный поток создается, прежде чем драйвер возвращается из функции обратного вызова create-stream EVT_ACX_CIRCUIT_CREATE_STREAM.
Для каналов с использованием нескольких контактов захвата и отрисовки, таких как host/offload/loopback/kws, т. е. при поддержке элемента аудио-обработчика драйвер должен создать потоковый мост без каких-либо встроенных объектов, а также вручную добавить входящие объекты ACXSTREAM в потоковый мост при обработке обратного вызова create-stream.
Дополнительные сведения о создании моста потоков см. в следующем разделе:
Распространение состояния автоматического потока с несколькими каналами на потоки нижнего уровня
ACXSTREA МБ RIDGE автоматически распространяет запрос состояния потока на удаленные каналы. При изменении состояния потока ACXSTREA МБ RIDGE вычисляет смешанное состояние внепотока и отправляет новый запрос "stream-state" в удаленный поток с помощью ACXTARGETSTREAM.
ACXSTREAM вместе с ACXSTREA МБ RIDGE использует следующую логику:
Измените состояния потоков вверх в следующих сценариях:
- Отрисовка &> из остановки> выполнения
- Запись &&& из остановки запуска>
- Другие &&переходы из остановки запуска>
Измените состояния потоков вверх в следующих сценариях:
- Отрисовка &> из остановки запуска>
- Запись &&& из остановки> выполнения
- Другие &&переходы из остановки запуска>
Драйверы могут изменить этот порядок с помощью параметра конфигурации.
Примечание.
Это требование для драйвера или канала или потока, чтобы всегда успешно переходы потоков от запуска до остановки. С другой стороны, драйвер может завершить работу обратного, т. е. от остановки выполнения.
См. также
Общие сведения о расширениях аудиоклассов ACX
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по