Алгоритм построителя конечной точки аудио

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

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

В 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 in 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. Заполняет конечную точку PropertyStore сведениями о свойствах из разделов реестра интерфейса звукового устройства.

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

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

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

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

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

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

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

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

• Один и тот же PropertyStore доступен независимо от того, как часто вы перезапускаете компьютер. Метаданные, связанные со звуковыми устройствами, сохраняются в конечной точке 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-файл, чтобы задать для конечной точки по умолчанию 16-разрядный формат PCM с частотой 44,1 кГц. После установки необходимо использовать панель управления или стороннее приложение, чтобы изменить формат конечной точки.

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

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

Отрисовка ранга	Записать ранг
Speakers	микрофон
Линейный выход	Вход в строку
SPDIF	SPDIF

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