Понятные имена для конечных звуковых устройств
В Windows Vista, Windows Server 2008 и более поздних версиях Windows звуковая подсистема поддерживает понятие конечного звукового устройства, например динамики, наушники, микрофоны и cd-проигрыватели. Эта концепция конечных точек звука помогает создавать удобные звуковые приложения с пользовательскими интерфейсами, которые ссылаются на конечные устройства, которыми непосредственно управляют пользователи. Эти конечные точки имеют понятные имена, такие как "динамики", "наушники", "микрофон" и "проигрыватель компакт-дисков", которые приложения могут отображать в своих пользовательских интерфейсах. Дополнительные сведения об устройствах конечных точек см. в разделе Аудиоустройства конечных точек.
Аудиосистема моделирует устройство Plug and Play (PnP) на звуковом адаптере в качестве фильтра KS. Потоки данных входят в фильтр и выходят из нее через маркеры KS. Контакт моста — это контакт KS, через который устройство конечной точки аудио подключается к фильтру KS. Дополнительные сведения о контактах моста см. в разделе Графы фильтра аудио.
Аудиосистема получает сведения об устройстве конечной точки аудио, проверяя свойства контакта моста, к которому подключается устройство конечной точки. Одним из таких свойств является свойство категории контактов (KSPROPERTY_PIN_CATEGORY).
Для каждого фильтра KS драйвер адаптера предоставляет таблицу PCPIN_DESCRIPTOR структур, описывающих свойства контактов KS в фильтре. GUID категории контактов хранится в элементе KsPinDescriptor.Category структуры PCPIN_DESCRIPTOR. Для контакта моста значение GUID категории контактов указывает тип конечной точки, которая подключается к контакту моста. Например, guid категории контактов KSNODETYPE_MICROPHONE указывает, что контакт моста подключается к микрофону, GUID KSNODETYPE_SPEAKER указывает, что контакт моста подключается к динамикам и т. д. Идентификаторы GUID KSNODETYPE_XXX определяются в файле заголовка Ksmedia.h.
Кроме того , PCPIN_DESCRIPTOR содержит GUID, который можно использовать для идентификации контакта по уникальному имени. Этот GUID имени контакта хранится в элементе KsPinDescriptor.Name структуры PCPIN_DESCRIPTOR. Этот GUID имени используется свойством (KSPROPERTY_PIN_NAME) для связывания понятного имени, найденного в реестре, с закреплением.
Звуковая подсистема вызывает свойство KSPROPERTY_PIN_NAME , чтобы связать понятное имя с конечной точкой звука. KS обрабатывает этот запрос, сначала выполняет поиск строки Юникода в реестре, описывающей GUID KsPinDescriptor.Name . Если KS не находит запись, она ищет в реестре строку Юникода, описывающую ИДЕНТИФИКАТОР KsPinDescriptor.Category .
Начиная с обновление Windows 10 за октябрь 2018 г. версии 1809, при поиске в реестре KS сначала ищет запись в программном ключе устройства. Он создается inf-файлом с помощью раздела AddReg, на который ссылается раздел [Модели] inf драйвера устройства. Раздел AddReg создает эти записи с помощью ключа HKR\MediaCategories. Это позволяет разработчику драйвера создавать понятные имена для идентификаторов GUID имени и категории, независимо от того, является ли GUID уникальным для устройства или нет.
Если запись не была установлена в программном ключе устройства или драйвер работает в операционной системе до Windows 10 версии 1809, KS проверяет раздел реестра MediaCategories. Этот второй ключ рассматривается как глобальное пространство имен. Начиная с Windows 10 версии 1809 это пространство зарезервировано для глобальных определений и не должно изменяться новыми драйверами. Изменение записей в этом разделе не будет поддерживаться в будущем выпуске ОС.
Звуковые устройства, предоставляющие пин-коды со стандартными категориями GUID, должны включать и нуждаться в почтовом ящике KS. INF или KSCAPTUR. Регистрация имени INF в INF-файле устройства. Эти входящие файлы содержат понятные определения имен по умолчанию для предварительно определенных GUID категорий, которые может потребоваться заполнить драйвером. Это те же идентификаторы GUID, что и в элементе KsPinDescriptor.Category структуры PCPIN_DESCRIPTOR. Например, запись GUID категории KSNODETYPE_MICROPHONE имеет связанное понятное имя "microphone", а guid категории KSNODETYPE_SPEAKER запись имеет связанное понятное имя "speakers" и т. д.
Guids and friendly names for Category and Name GUID хранятся в реестре. Для каждой пары GUID-имя в реестре строка GUID используется в качестве подключа в разделе MediaCategories. Под ключом GUID понятное имя строкового значения Юникода в переменной Name.
Если ни одна из понятных имен и категорий контактов, определенных звуковой подсистемой, не соответствует вашему устройству, вы можете определить собственную категорию контактов и имена GUID и связать с ними понятные имена в inf. Чтобы убедиться, что GUID категории контактов является уникальным, используйте служебную программу, например Uuidgen.exe для создания GUID. Затем измените INF-файл, устанавливающий аудиоадаптер, чтобы записать GUID категории контактов и понятное имя в реестр. В следующем примере кода показан фрагмент INF-файла, который добавляет в реестр два идентификатора GUID категории контактов и связанные с ними понятные имена:
[Manufacturer]
MyOEMName=Unicorn,NTamd64
[Unicorn.NTamd64]
MyDeviceName=MyDevice,Root\MyDevice
[MyDevice.NT]
Include=ks.inf, kscaptur.inf
Needs=KS.Registration, KSCAPTUR.Registration.NT
CopyFiles=MyDevice.CopyFiles
AddReg=PinNameRegistration
...
[PinNameRegistration]
HKR,%MediaCategories%\%GUID.MyNewEndpointCategory%,Name,,%Name.MyNewEndpointCategory%
HKR,%MediaCategories%\%GUID.MyNewEndpointName%,Name,,%Name.MyNewEndpointName%
...
[Strings]
MyOEMName="Unicorns Inc."
MyDeviceName="Sparkly Unicorn"
MediaCategories="MediaCategories"
GUID.MyNewEndpointCategory="{B72FBD1A-4634-4240-B207-0E6B52F3701C}"
GUID.MyNewEndpoint_2="{71DD3A5D-E303-49A0-ACEE-908634AA9520}"
Name.MyNewEndpointCategory="Unicorn"
Name.MyNewEndpointName="Fred the Unicorn"
Обе строки GUID были созданы Uuidgen.exe.
Приложения могут получить доступ к свойствам устройства конечной точки аудио с помощью интерфейса IPropertyStore устройства. Для идентификации свойств интерфейс использует ключи свойств, определенные в файлах заголовков Functiondiscoverykeys_devpkey.h и Mmdeviceapi.h. Приложение может использовать ключ свойства PKEY_Device_FriendlyName для получения понятного имени устройства конечной точки. Для пользовательских интерфейсов с ограниченным пространством можно получить более короткую версию понятного имени с помощью ключа свойства PKEY_Device_DeviceDesc . Дополнительные сведения об этих ключах свойств см. в разделе IMMDevice::OpenPropertyStore.
Экземпляр интерфейса IPropertyStore поддерживает постоянное хранилище свойств для устройства конечной точки аудио. Хранилище свойств копирует свое начальное значение для ключа свойства PKEY_Device_DeviceDesc из понятной строки имени, связанной с GUID категории ks pin в реестре. Приложения могут считывать значение свойства PKEY_Device_DeviceDesc (строку имени) из хранилища свойств, но не могут изменить это значение. Однако пользователи могут изменить имя с помощью панели управления мультимедиа Windows, Mmsys.cpl. Например, в Windows Vista для изменения имени устройства конечной точки отрисовки можно выполнить следующие действия:
Чтобы запустить Mmsys.cpl, откройте окно командной строки и введите следующую команду:
mmsys.cpl(Кроме того, можно запустить Mmsys.cpl, щелкнув правой кнопкой мыши значок динамика в области уведомлений, расположенной в правой части панели задач, и выбрав пункт Устройства воспроизведения.)
Щелкните имя устройства отрисовки и нажмите кнопку Свойства.
В окно свойств откройте вкладку Общие. Понятное имя должно отображаться в текстовом поле в верхней части страницы свойств. Вы можете изменить понятное имя, а затем сохранить изменения, нажав кнопку ОК.
На предыдущих шагах изменяется понятное имя, которое хранится в хранилище свойств для конечного аудиоустройства. Эти действия не влияют на понятные имена, связанные с другими конечными аудиоустройствами, которые относятся к той же категории контактов KS. Они также не влияют на какие-либо компоненты, которые могут запрашивать KS напрямую для получения имени.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по