Алгоритм конфигуратора аудио конечных точек

В Windows Vista и более поздних версиях Windows AudioEndpointBuilder — это системная служба, которая перечисляет, инициализирует и активирует звуковые конечные точки в системе. В этом разделе представлен обзор алгоритма, используемого службой AudioEndpointBuilder.

Служба AudioEndpointBuilder использует алгоритм для обнаружения и перечисления конечных точек. Алгоритм был разработан для упрощения системного доступа к мультиплексированным (MUXed) устройствам захвата, а также для работы с топологиями, включающими несколько контактов хоста, несколько контактов моста или и то и другое.

В Windows XP звуковая модель использовала термин аудиоустройства для ссылки на концептуальное устройство в дереве Plug and Play (PnP). В Windows Vista и более поздних версиях Windows концепция звукового устройства была изменена, чтобы лучше представить устройство, с которым пользователь физически взаимодействует.

С помощью двух новых API в Windows Vista API MMDevice и WASAPI вы можете получить доступ к этим новым звуковым устройствам и управлять ими. API MMDevice называет новые звуковые устройства конечными точками.

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

В следующем списке показано, как работает алгоритм, используемый AudioEndpointBuilder:

1. Ищет любые несоединенные штепсельные контакты моста.

2. Создает конечную точку для любого несоединенного штифта моста. Например, когда AudioEndpointBuilder находит несоединенный штырь моста с GUID категории контактов KSNODETYPE_SPEAKER, он создает конечную точку динамика для этого штыря моста. Дополнительные сведения о KSNODETYPE_SPEAKER и других GUID категорий пинов см. в файле Ksmedia.h из WinDDK\<build number>\inc\api.

3. Задает свойства по умолчанию для конечной точки. Например, AudioEndpointBuilder задает имя, значок и форм-фактор.

4. Определяет, существует ли путь от конечной точки к контактному пину, который поддерживает модуляцию пульсового кода (PCM), аудиокодек-3 (AC3) или видео Windows Media (WMV). Главный пин — это структура KSPIN при установленном элементе Communication в KSPIN_COMMUNICATION_SINK или KSPIN_COMMUNICATION_BOTH. Дополнительные сведения о структуре KSPIN см. в разделе KSPIN.

5. Заполняет endpoint PropertyStore информацией о свойствах из ключей реестра интерфейса аудиоустройства.

6. Задает состояние конечной точки. Состояние конечной точки может быть одним из следующих трех значений:

   • Активный. Это означает, что путь существует, как описано на шаге 4.

   • Отключен. Если звуковое устройство поддерживает обнаружение джека, это состояние указывает, что путь существует для конечной точки, и разъем отключается из физического соединителя на звуковом адаптере.

   • Нет. Это состояние указывает, что путь не найден на шаге 4, а обнаружение джека не поддерживается этой конечной точкой.

7. Задает эту конечную точку в качестве конечной точки по умолчанию, если это то, что указано в связанном INF-файле.

После перечисления конечных точек клиенты звуковой системы могут управлять ими напрямую с помощью новых API Windows Vista (как указано ранее) или косвенно с помощью более знакомых API, таких как Wave, DirectShow или DirectSound. Были предоставлены новые методы API, чтобы звуковые клиенты могли начать с идентификатора MMDevice конечной точки и получить доступ к идентификатору Wave или DirectSound для той же конечной точки.

При использовании конечных точек можно воспользоваться следующими преимуществами:

• Один и тот же глобальный уникальный идентификатор (GUID) доступен независимо от частоты перезапуска компьютера. Наличие этого постоянного GUID более надежно, чем сохранение идентификатора waveOut или удобочитаемого имени конечной точки.

• То же свойство PropertyStore доступно независимо от частоты перезапуска компьютера. Метаданные, связанные с звуковым устройством, сохраняются в endpoint PropertyStore.

• Мультиплексированные (MUX) и деплексированные (DEMUX) пин-коды управляются автоматически и перечисляются службой AudioEndpointBuilder.

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

• Правила именования Соглашение об именовании, используемое для конечных точек, основано на понятных именах контактов моста. Однако в случае конечных точек громкоговорителей имя жестко закодировано как "Динамики" и не может быть изменено драйвером или сторонним приложением.

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

  • Скрытые конечные точки

    На следующей схеме фильтр KS отображается с двумя контактными выводами, подключенными к одному контакту моста (Динамик).

    

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

    

    На предыдущей схеме проблематичная топология была перепроектирована так, что AudioEndpointBuilder может обнаружить два контактных соединения узла (PCM и AC-3/PCM), поскольку теперь он может видеть два контактных соединения моста (аудиоколонка и SPDIF).

  • Разделители

    Другой тип неоптимальной топологии создается, когда один хост соединяется с несколькими контактами моста. На следующей схеме показана топология, в которой контакт хоста PCM подключается к контакту моста динамика и к контакту моста SPDIF.

    

    В этом случае AudioEndpointBuilder обнаруживает один штырь обвязки, трассирует путь к хостовому штырю PCM, задает значения по умолчанию, а затем создает и активирует конечную точку динамика. Когда AudioEndpointBuilder обнаруживает следующий мостовой контакт, он прокладывает маршрут обратно к тому же контакту PCM, задает значения по умолчанию, а затем создает и активирует конечный пункт SPDIF. Однако, хотя обе конечные точки инициализированы и активированы, потоковая передача в одну из них делает невозможной потоковую передачу в другую одновременно; другими словами, они являются взаимоисключающими конечными точками.

    На следующей схеме показана реорганизация этой топологии, в которой существуют отдельные подключения. Эта конструкция дает возможность AudioEndpointBuilder отследить путь к хост-контакту PCM для каждого из двух контактов мостового соединения.

    

• Формат конечной точки. Если звуковой модуль работает в общем режиме, формат конечной точки предполагает определенный параметр, как показано в INF-файле во время установки. Например, звуковой драйвер для звукового устройства использует связанный с ним INF-файл, чтобы задать конечную точку по умолчанию 44,1 кГц, 16-разрядный формат стерео PCM. После установки необходимо использовать панель управления или стороннее приложение для изменения формата конечной точки.

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

Заметка Если INF-файл не выбирает конечную точку для установки по умолчанию, клиентское приложение может использовать API MMDevice для выбора конечной точки. API основывает свой выбор на ранге форм-фактора и на том, является ли конечная точка точкой отрисовки или записи. В следующей таблице показан порядок выбора.

Ранжирование рендеринга	Ранжирование записи
Докладчики	Микрофон
Линейный выход	Линейный вход
SPDIF	SPDIF

Если вы используете API MMDevice для выбора конечной точки по умолчанию, а доступные конечные точки ранжируются одинаково, API MMDevice будет алфавитизировать идентификаторы конечных точек, чтобы определить, какая конечная точка будет выбрана по умолчанию. Например, если аудиоадаптер имеет соединители линейного выхода и входа, а связанный INF-файл не устанавливает один из них как значение по умолчанию во время установки, API MMDevice определяет, какой идентификатор конечной точки будет первым в алфавитном порядке, и устанавливает этот соединитель в качестве значения по умолчанию. Этот выбор сохраняется после перезапуска системы, так как идентификаторы конечных точек являются постоянными. Однако выбор не сохраняется, если в системе отображается более ранжная конечная точка (например, второй адаптер с соединителем микрофона).