Partilhar via


Algoritmo de Construção do Ponto de Extremidade de Áudio

No Windows Vista e versões posteriores do Windows, o AudioEndpointBuilder é um serviço do sistema que enumera, inicializa e ativa os pontos de extremidade de áudio em um sistema. Este tópico fornece uma visão geral do algoritmo usado pelo serviço AudioEndpointBuilder.

O serviço AudioEndpointBuilder usa um algoritmo para descobrir e enumerar pontos de extremidade. O algoritmo foi projetado para simplificar o acesso do sistema a dispositivos de captura multiplexados (MUXed) e para ajudar a trabalhar com topologias que envolvem vários pinos de host e vários pinos de ponte, ou ambos.

No Windows XP, o modelo de áudio usava o termo dispositivo de áudio para se referir a um dispositivo conceitual na árvore Plug and Play (PnP). No Windows Vista e versões posteriores do Windows, o conceito de um dispositivo de áudio foi redesenhado para representar melhor o dispositivo com o qual o usuário interage fisicamente.

Com duas novas APIs no Windows Vista, MMDevice API e WASAPI, você pode acessar e manipular esses novos dispositivos de áudio. A API MMDevice refere-se aos novos dispositivos de áudio como pontos de extremidade.

O serviço AudioEndpointBuilder monitoriza a classe KSCATEGORY_AUDIO para as chegadas e remoções de interfaces de dispositivos. Quando um driver de dispositivo de áudio registra uma nova instância da classe de interface de dispositivo KSCATEGORY_AUDIO, o serviço AudioEndpointBuilder deteta a notificação da interface do dispositivo e usa um algoritmo para examinar a topologia dos dispositivos de áudio no sistema e tomar as medidas apropriadas.

A lista a seguir resume como o algoritmo usado pelo AudioEndpointBuilder funciona:

  1. Verifica pinos de ligação desconectados.

  2. Cria um ponto de extremidade para quaisquer pinos de ponte não conectados. Por exemplo, quando o AudioEndpointBuilder encontra um pino de ponte não conectado com um GUID de categoria de pino de KSNODETYPE_SPEAKER, ele cria um ponto de extremidade de alto-falante para esse pino de ponte. Para obter mais informações sobre KSNODETYPE_SPEAKER e outros GUIDs de categoria de pino, consulte Ksmedia.h em WinDDK\<build number>\inc\api.

  3. Define as propriedades padrão para o ponto de extremidade. Por exemplo, AudioEndpointBuilder define o nome, o ícone e o fator de forma.

  4. Determina se há um caminho do ponto de extremidade para um pino de host que oferece suporte à modulação de código de pulso (PCM), ao codec de áudio 3 (AC3) ou ao vídeo de mídia do Windows (WMV). Um pino de host é uma estrutura KSPIN com o seu membro Communication definido como KSPIN_COMMUNICATION_SINK ou KSPIN_COMMUNICATION_BOTH. Para obter mais informações sobre a estrutura KSPIN, consulte KSPIN.

  5. Preenche o endereço PropertyStore com informações de propriedade das chaves do registo da interface de dispositivo de áudio.

  6. Configura o estado do endpoint. O estado do ponto de extremidade pode ser um dos três valores a seguir:

    • Ativo. Isso indica que existe um caminho conforme descrito na Etapa 4.

    • Desconectado. Se o dispositivo de áudio suportar a deteção de tomada, esse estado indica que existe um caminho para o ponto de extremidade e a tomada está desconectada do conector físico no adaptador de áudio.

    • Não está presente. Este estado indica que um caminho não foi encontrado na etapa 4 e a detecção de jack não é suportada por este ponto final.

  7. Define esse ponto de extremidade como o ponto de extremidade padrão, se for isso especificado no arquivo INF associado.

Depois que os pontos de extremidade tiverem sido enumerados, os clientes do sistema de áudio podem manipulá-los diretamente usando as novas APIs do Windows Vista (conforme indicado anteriormente) ou indiretamente usando as APIs mais familiares, como Wave, DirectShow ou DirectSound. Novos métodos de API foram fornecidos para que os clientes de áudio possam começar com a ID MMDevice de um ponto de extremidade e acessar a ID Wave ou DirectSound para o mesmo ponto de extremidade.

Ao usar endpoints, pode tirar proveito do seguinte:

  • O mesmo GUID (ID exclusivo global) está disponível independentemente da frequência com que você reinicia a máquina. Possuir este GUID persistente é mais confiável do que guardar um ID waveOut ou um nome amigável para o ponto de extremidade.

  • O mesmo PropertyStore está disponível independentemente da frequência com que reinicia o computador. Os metadados relacionados ao dispositivo de áudio são salvos no PropertyStore do ponto de extremidade.

  • Os pinos multiplexados (MUX) e desmultiplexados (DEMUX) são gerenciados automaticamente e enumerados pelo serviço AudioEndpointBuilder.

Se desenvolveres o teu próprio controlador para dispositivo de áudio e ficheiro INF para funcionar com o teu dispositivo de áudio, e desenvolveres uma aplicação de áudio, ou ambos, é aconselhável estares ciente dos seguintes problemas e práticas recomendadas. Ao desenvolver drivers e aplicativos com essas recomendações em mente, você produz drivers, arquivos INF e clientes de áudio que funcionam de forma mais eficaz com o AudioEndpointBuilder.

  • Convenção de nomenclatura. A convenção de nomenclatura usada para os pontos de extremidade é baseada nos nomes amigáveis dos pinos de ponte. No entanto, no caso de pontos de saída de áudio, o nome foi predefinido para "Alto-falantes" e não pode ser alterado pelo seu driver ou por uma aplicação de terceiros.

  • Topologias subótimas. Certas topologias são consideradas subótimas devido ao algoritmo usado pelo AudioEndpointBuilder para enumerar pontos de extremidade. Por exemplo, ao criar uma dessas topologias subideais, você cria pinos de host que têm pontos de extremidade ocultos e não podem ser vistos pelo AudioEndpointBuilder ou divisores (pontos de extremidade divididos) que o AudioEndpointBuilder não pode vincular aos pinos de host associados.

    • Pontos finais ocultos

      No diagrama a seguir, o filtro KS é mostrado como tendo dois pinos de host que estão conectados a um único pino de ponte (Speaker).

      Diagrama mostrando topologia problemática com pino de anfitrião AC-3 e ponto final oculto no lado esquerdo, PCM individual e AC-3 compartilhando um único filtro.

      Quando o AudioEndpointBuilder descobre esse pino de ponte, ele rastreia um caminho de volta para apenas um dos pinos de host, define os valores padrão para o pino de ponte, cria e ativa um ponto de extremidade de alto-falante e continua a descobrir outros pinos de ponte. Assim, o outro pino de host permanece oculto do AudioEndpointBuilder.

      Diagrama ilustrando topologia recomendada com caminhos rastreáveis entre pinos de host e pontos de extremidade.

      No diagrama anterior, a topologia problemática foi redesenhada para que o AudioEndpointBuilder possa descobrir os dois pinos de host (PCM e AC-3 / PCM) porque agora pode ver dois pinos de ponte (Speaker e SPDIF).

    • Divisores

      Outro tipo de topologia subótima é criado quando um pino de host se conecta a mais de um pino de ponte. O diagrama a seguir mostra uma topologia na qual um pino de host PCM se conecta a um pino de ponte de alto-falante e a um pino de ponte SPDIF.

      Diagrama representando topologia problemática com dois pontos de extremidade conectados a um pino de host e PCM único.

      Nesse caso, o AudioEndpointBuilder descobre um pino de ponte e rastreia um caminho de volta para o pino do host PCM, define valores padrão e, em seguida, cria e ativa um ponto de extremidade de alto-falante. Quando o AudioEndpointBuilder descobre o próximo pino de ponte, ele rastreia um caminho de volta para o mesmo pino de host PCM, define valores padrão e, em seguida, cria e ativa um ponto de extremidade SPDIF. No entanto, embora ambos os pontos de extremidade tenham sido inicializados e ativados, o streaming para um deles torna impossível transmitir para o outro ao mesmo tempo; por outras palavras, são pontos de extremidade mutuamente exclusivos.

      O diagrama a seguir mostra um redesign dessa topologia na qual existem conexões separadas. Esse design possibilita que o AudioEndpointBuilder rastreie um caminho de volta ao pino de host PCM para cada um dos dois pinos de ponte.

      Diagrama ilustrando topologia recomendada com caminhos rastreáveis entre pinos de host e pontos de extremidade, com dois PCMs no lado esquerdo.

  • Formato do ponto final. Quando o mecanismo de áudio está a funcionar no modo partilhado, o formato do endpoint assume uma configuração específica, conforme indicado pelo arquivo INF no momento da instalação. Por exemplo, o driver de áudio para um dispositivo de áudio usa seu arquivo INF associado para definir o ponto de extremidade padrão para um formato PCM estéreo de 44,1 kHz e 16 bits. Após a instalação, deve usar o Painel de Controlo ou uma aplicação de terceiros para alterar o formato do endpoint.

  • Dispositivo padrão. O ponto de extremidade definido como o dispositivo padrão é selecionado no momento da instalação usando informações no arquivo INF. Após a conclusão da instalação, você deve usar o Painel de Controle ou um aplicativo de terceiros para selecionar outro ponto de extremidade para ser o ponto de extremidade padrão.

Observação Se o arquivo INF não selecionar um ponto de extremidade a ser definido como padrão durante a instalação, um aplicativo cliente poderá usar a API MMDevice para selecionar um ponto de extremidade. A API baseia sua seleção na classificação do fator de forma e se o endpoint é de renderização ou de captura. A tabela a seguir mostra a ordem de seleção.

Classificação de renderização Classificação de captura
Oradores Microfone
Saída de linha Entrada de linha
SPDIF SPDIF

Se você usar a API MMDevice para selecionar um ponto de extremidade padrão e os pontos de extremidade disponíveis forem classificados da mesma forma, a API MMDevice alfabetizará os IDs de ponto de extremidade para determinar qual ponto de extremidade selecionar como padrão. Por exemplo, se um adaptador de áudio tiver conectores de saída e entrada de linha e o arquivo INF associado não selecionar nenhum deles como padrão no momento da instalação, a API MMDevice identificará quais IDs de ponto de extremidade são os primeiros em ordem alfabética e definirá esse conector como padrão. Essa seleção persiste depois de reiniciares o sistema porque os IDs de endpoint são persistentes. No entanto, a seleção não persiste se um ponto de extremidade de maior classificação (por exemplo, um segundo adaptador com um conector de microfone) surge no sistema.