Compartilhar via


Drivers USB Audio 2.0

A partir do Windows 10, versão 1703, um driver USB Audio 2.0 é fornecido com o Windows. Ele foi projetado para dar suporte à classe de dispositivo USB Audio 2.0. O driver é um miniporto de classe de porta de áudio WaveRT.

O driver é nomeado: usbaudio2.sys e o arquivo inf associado é usbaudio2.inf.

O driver será identificado no gerenciador de dispositivos como "Dispositivo de Áudio Classe 2 USB". Esse nome será substituído por uma string de produto USB, se estiver disponível.

O driver é habilitado automaticamente quando um dispositivo compatível é anexado ao sistema. No entanto, se houver um driver de terceiros no sistema ou no Windows Update, esse driver será instalado e substituirá o driver de classe.

Arquitetura

O driverusbaudio2.sys se encaixa na arquitetura mais ampla do Áudio USB do Windows, conforme mostrado.

Diagrama de pilha ilustrando a arquitetura de áudio USB do Windows com ks.sys na parte superior e dispositivos de áudio USB na parte inferior.

As especificações USB a seguir definem o áudio USB e são referenciadas neste artigo.

  • USB-2 refere-se à Especificação do Barramento Serial Universal, Revisão 2.0
  • ADC-2 refere-se à definição de classe de dispositivo USB para dispositivos de áudio, versão 2.0.
  • FMT-2 refere-se à especificação formatos de dados de áudio, versão 2.0.

O USB-IF é um grupo de interesse especial que mantém a Especificação USB Oficial, as especificações de teste e as ferramentas.

Formatos de áudio

O driver dá suporte aos formatos listados abaixo. Uma configuração alternativa, que especifica outro formato definido em FMT-2 ou um formato desconhecido, será ignorada.

Formatos de tipo I (FMT-2 2.3.1):

  • Formato PCM com 8,32 bits por amostra (FMT-2 2.3.1.7.1)
  • Formato PCM8 (FMT-2 2.3.1.7.2)
  • Formato IEEE_FLOAT (FMT-2 2.3.1.7.3)

Formatos do tipo III (FMT-2 2.3.3 e A.2.3):

  • IEC61937_AC-3
  • IEC61937_MPEG-2_AAC_ADTS
  • IEC61937_DTS-I
  • IEC61937_DTS-II
  • IEC61937_DTS-III
  • TYPE_III_WMA

Descrições de recursos

Esta seção descreve os recursos do driver USB Audio 2.0.

Topologia de função de áudio

O driver dá suporte a todos os tipos de entidade definidos no ADC-2 3.13.

Cada Entidade de Terminal deve ter uma conexão de relógio válida no hardware compatível com o USB Audio 2.0. Opcionalmente, o caminho do relógio pode incluir unidades de Multiplicador de Relógio e Seletor de Relógio e deve terminar em uma Entidade de Origem do Relógio.

O driver dá suporte apenas a uma única fonte de relógio. Se um dispositivo implementar várias entidades de origem de relógio e um seletor de relógio, o driver usará a origem do relógio selecionada por padrão e não modificará a posição do seletor de relógio.

Não há suporte para uma unidade de processamento (ADC-2 3.13.9) com mais de um pino de entrada.

Não há suporte para uma unidade de extensão (ADC-2 3.13.10) com mais de um pino de entrada.

Caminhos cíclicos na topologia não são permitidos.

Streaming de áudio

O driver dá suporte aos seguintes tipos de sincronização de terminais (USB-2 5.12.4.1):

  • ENTRADA e SAÍDA assíncronas
  • ENTRADA e SAÍDA síncronas
  • Entrada e Saída Adaptáveis

Para o caso OUT assíncrono, o driver dá suporte apenas a feedback explícito. Um ponto de feedback deve ser implementado na respectiva configuração alternativa da interface AS. O driver não dá suporte a comentários implícitos.

Atualmente, há suporte limitado para dispositivos que usam um relógio compartilhado para vários pontos de extremidade.

Para o Adaptive IN, caso o driver não dê suporte a um ponto de extremidade de avanço do feed. Se esse ponto de extremidade estiver presente na configuração alternativa, ele será ignorado. O driver manipula o fluxo IN adaptativo da mesma forma que um fluxo IN assíncrono.

O tamanho dos pacotes isocronos criados pelo dispositivo deve estar dentro dos limites especificados na seção FMT-2.0 2.3.1.1. Isso significa que o desvio do tamanho real do pacote em relação ao tamanho nominal não deve exceder +/- um slot de áudio (slot de áudio = amostras de contagem de canais).

Descritores

Uma função de áudio deve implementar exatamente um Descritor de Interface AudioControl (ADC-2 4.7) e um ou mais descritores de interface audiostreaming (ADC-2 4.9). Uma função com uma interface de controle de áudio, mas não há suporte para nenhuma interface de streaming.

O driver dá suporte a todos os tipos de descritor definidos no ADC-2, seção 4. As subseções a seguir fornecem comentários sobre alguns tipos específicos de descritor.

Descritor de interface AS Class-Specific

Para obter detalhes sobre essa especificação, consulte a ADC-2 4.9.2.

Um descritor de interface AS deve começar com a configuração alternativa zero sem ponto de extremidade (sem consumo de largura de banda) e outras configurações alternativas devem ser especificadas em ordem crescente no hardware compatível com o USB Audio 2.0.

Uma configuração alternativa com um formato que não é compatível com o driver será ignorada.

Cada configuração alternativa diferente de zero deve especificar um ponto de extremidade de dados isócrono e, opcionalmente, um ponto de extremidade de feedback. Não há suporte para uma configuração alternativa diferente de zero sem nenhum ponto de extremidade.

O campo bTerminalLink deve se referir a uma Entidade de Terminal na topologia e seu valor deve ser idêntico em todas as configurações alternativas de uma interface AS.

O campo bFormatType no descritor de interface AS deve ser idêntico ao bFormatType especificado no Descritor de Tipo de Formato (FMT-2 2.3.1.6).

Para formatos de Tipo I, exatamente um bit deve ser definido como um no campo bmFormats do descritor de interface AS. Caso contrário, o formato será ignorado pelo driver.

Para economizar largura de banda do barramento, uma interface AS pode implementar várias configurações alternativas com o mesmo formato (em termos de bNrChannels e descritor de tipo de formato AS), mas com diferentes valores de wMaxPacketSize no descritor de ponto de extremidade de dados isócronos. Para uma determinada taxa de amostragem, o driver seleciona a configuração alternativa com o menor wMaxPacketSize que pode atender aos requisitos de taxa de dados.

Descritor de formato de tipo I

Para obter detalhes sobre essa especificação, consulte FMT-2 2.3.1.6.

As restrições a seguir se aplicam:

Formato Tamanho do sublote Resolução de bits
Formato pcm do tipo I: 1 <= bSubslotSize <= 4 8 <= bBitResolution <= 32
Formato PCM8 do tipo I: bSubslotSize == 1 bBitResolution == 8
Formato Tipo I IEEE_FLOAT bSubslotSize == 4 bBitResolution == 32
Formatos de IEC61937 tipo III: bSubslotSize == 2 bBitResolution == 16

Class-Specific descritor de ponto de extremidade de dados de áudio isócrono AS

Para obter detalhes sobre essa especificação, consulte a ADC-2 4.10.1.2.

O sinalizador MaxPacketsOnly no campo bmAttributes não tem suporte e será ignorado.

Os campos bmControls, bLockDelayUnits e wLockDelay serão ignorados.

Solicitações de classe e mensagens de dados de interrupção

O driver dá suporte a um subconjunto das solicitações de controle definidas no ADC-2, seção 5.2 e dá suporte a mensagens de dados de interrupção (ADC-2 6.1) para alguns controles. A tabela a seguir mostra o subconjunto implementado no driver.

Entidade Controle GET CUR SET CUR GET INTERVALO INTERROMPER
Origem do relógio Controle de frequência de amostragem x x x
Seletor de Relógio Controle seletor de relógio x
Multiplicador de Relógio Controle do Numerador x
Controle de denominador x
Terminal Controle do conector x x
Unidade do mixer Controle do mixer x x x
Unidade seletora Controle seletor x x
Unidade de Recursos Controle de Silêncio x x x
Controle de volume x x x x
Controle de ganho automático x x
Unidade de efeito
Unidade de processamento
Unidade de extensão

Informações adicionais sobre os controles e solicitações estão disponíveis nas subseções a seguir.

Entidade de origem do relógio

Para obter detalhes sobre essa especificação, consulte a ADC-2 5.2.5.1.

No mínimo, uma Entidade de Origem de Relógio deve implementar as solicitações GET RANGE de Controle de Frequência de Amostragem e GET CUR (ADC-2 5.2.5.1.1) em hardware USB Audio 2.0 compatível.

A solicitação GET RANGE do Controle de Frequência de Amostragem retorna uma lista de subranges (ADC-2 5.2.1). Cada subconjunto descreve uma frequência discreta ou um intervalo de frequência. Uma frequência de amostragem discreta deve ser expressa definindo os campos MIN e MAX como a respectiva frequência e RES como zero. Subintervalos individuais não devem se sobrepor. Se um subintervalo se sobrepor a um anterior, será ignorado pelo driver.

Uma Entidade de Origem de Relógio que implementa apenas uma única frequência fixa não precisa implementar o Controle de Frequência de Amostragem SET CUR. Ele implementa GET CUR, que retorna a frequência fixa e implementa GET RANGE, que relata uma única frequência discreta.

Entidade do seletor de relógio

Para obter detalhes sobre essa especificação, consulte a ADC-2 5.2.5.2

O driver usb audio 2.0 não dá suporte à seleção de relógio. O driver usa a Entidade de Origem do Relógio, que é selecionada por padrão e nunca emite uma solicitação SET CUR do Controle do Seletor de Relógio. A solicitação GET CUR do Controle do Seletor de Relógio (ADC-2 5.2.5.2.1) deve ser implementada em hardware USB Audio 2.0 compatível.

Unidade de funcionalidade

Para obter detalhes sobre essa especificação, consulte a ADC-2 5.2.5.7.

O driver dá suporte apenas a um único intervalo de volumes. Se a solicitação GET RANGE de Controle de Volume retornar mais de um intervalo, os intervalos subsequentes serão ignorados.

O intervalo de volume expresso pelos campos MIN e MAX deve ser um múltiplo inteiro do tamanho da etapa especificado no campo RES.

Se uma unidade de recurso implementar controles de canal único e um controle mestre para Mudo ou Volume, o driver usará os controles de canal único e ignorará o controle mestre.

Informações adicionais para OEM e IHVs

OEMs e IHVs devem testar seus dispositivos existentes e novos no driver embutido fornecido.

Não há nenhuma personalização de parceiro específica associada ao driver padrão de Áudio USB 2.0.

Essa entrada de arquivo INF (fornecida em uma atualização para o Windows Release 1703) é usada para identificar que o driver in-box é um driver de dispositivo genérico.

GenericDriverInstalled,,,,1

O driver in-box registra as seguintes IDs compatíveis com usbaudio2.inf.

USB\Class_01&SubClass_00&Prot_20
USB\Class_01&SubClass_01&Prot_20
USB\Class_01&SubClass_02&Prot_20
USB\Class_01&SubClass_03&Prot_20

Consulte a especificação de Áudio USB 2.0 para tipos de subclasse.

Dispositivos USB Audio 2.0 com MIDI (subclasse 0x03 mencionada acima) enumerarão a função MIDI separadamente como um dispositivo de múltiplas funções com usbaudio.sys (driver de áudio USB 1.0) ativado.

O driver da classe USB Audio 1.0 registra este identificador compatível com wdma_usb.inf.

USB\Class_01

E tem estas exclusões:

USB\Class_01&SubClass_00&Prot_20
USB\Class_01&SubClass_01&Prot_20
USB\Class_01&SubClass_02&Prot_20
USB\Class_01&SubClass_03&Prot_20

Não há suporte para um número arbitrário de canais (maior que oito) no modo compartilhado devido a uma limitação da pilha de áudio do Windows.

Drivers e atualizações do IHV USB Audio 2.0

Para drivers USB Audio 2.0 de terceiros fornecidos pelo IHV, esses drivers continuarão a ser preferidos para seus dispositivos em vez de nosso driver embutido, a menos que eles atualizem seu driver para substituir explicitamente esse comportamento e usar o driver embutido.

Descrições do Registro do Audio Jack

A partir do Windows 10 versão 1703, os IHVs responsáveis por criar dispositivos USB Audio Class 2.0 com uma ou mais tomadas têm a capacidade de descrever essas tomadas para o driver embutido de Classe de Áudio 2.0 do Windows. O driver in-box utiliza as informações fornecidas ao lidar com a KSPROPERTY_JACK_DESCRIPTION deste dispositivo.

As informações de jack são armazenadas no registro na chave de instância do dispositivo (chave HW).

O seguinte descreve as configurações do conector de áudio no registro:

REG_DWORD  T<tid>_NrJacks                 # of the jack on this device
REG_DWORD  T<tid>_J<n>_ChannelMapping     Channel mask. The value is defined in ksmedia.h. e.g. SPEAKER_FRONT_RIGHT or KSAUDIO_SPEAKER_5POINT1_SURROUND
REG_DWORD  T<tid>_J<n>_ConnectorType      The enum value is define in EPcxConnectionType.
REG_DWORD  T<tid>_J<n>_GeoLocation        The enum value is define in EPcxGeoLocation.
REG_DWORD  T<tid>_J<n>_GenLocation        The enum value is define in EPcxGenLocation.
REG_DWORD  T<tid>_J<n>_PortConnection     The enum value is define in EPxcPortConnection.
REG_DWORD  T<tid>_J<n>_Color              The color needs to be represent by RGB like this: 0x00RRGGBB (NOT a COLORREF).

<tid> = ID do terminal (conforme definido no descritor)

<n> = Número do jack (1 ~ n).

A convenção para <tid> e <n> é:

  • Base 10 (8, 9, 10 em vez de 8, 9, a)
  • Sem zeros à esquerda
  • n é baseado em 1 (o primeiro jack é jack 1 em vez de jack 0)

Por exemplo:

T1_NrJacks, T1_J2_ChannelMapping, T1_J2_ConnectorType

Para obter mais informações sobre o conector de áudio, consulte a estrutura KSJACK_DESCRIPTION.

Esses valores do Registro podem ser definidos de várias maneiras:

  • Usando INFs personalizados, que encapsulam o INF incluído com a finalidade de definir esses valores.

  • Diretamente pelo dispositivo de hardware por meio de um Descritor do Sistema Operacional da Microsoft para dispositivos USB (veja o exemplo abaixo). Para obter mais informações sobre como criar esses descritores, consulte Descritores do sistema operacional da Microsoft para dispositivos USB.

Exemplo de descritores do sistema operacional da Microsoft para USB

O exemplo de descritores do sistema operacional Microsoft para USB a seguir contém o mapeamento de canal e a cor de uma tomada. O exemplo é para um dispositivo não composto com descritor de recurso único.

O fornecedor de IHV deve estendê-lo para conter qualquer outra informação para a descrição do jack.

UCHAR Example2_MSOS20DescriptorSetForUAC2 [0x76] = {
    //
    // Microsoft OS 2.0 Descriptor Set Header
    //
    0x0A, 0x00,             // wLength - 10 bytes
    0x00, 0x00,             // MSOS20_SET_HEADER_DESCRIPTOR
    0x00, 0x00, 0x0?, 0x06, // dwWindowsVersion – 0x060?0000 for future Windows version
    0x76, 0x00,             // wTotalLength – 118 bytes // update later

    //
    // Microsoft OS 2.0 Registry Value Feature Descriptor
    //
    0x42, 0x00,             // bLength - 66 bytes
    0x04, 0x00,             // wDescriptorType – 5 for Registry Property
    0x04, 0x00,             // wPropertyDataType - 4 for REG_DWORD
    0x34, 0x00,             // wPropertyNameLength – 52 bytes
    0x54, 0x00, 0x30, 0x00, // Property Name - "T01_J01_ChannelMapping"
    0x31, 0x00, 0x5f, 0x00,
    0x4a, 0x00, 0x30, 0x00,
    0x31, 0x00, 0x5f, 0x00,
    0x43, 0x00, 0x68, 0x00,
    0x61, 0x00, 0x6e, 0x00,
    0x6e, 0x00, 0x65, 0x00,
    0x6c, 0x00, 0x4d, 0x00,
    0x61, 0x00, 0x70, 0x00,
    0x70, 0x00, 0x69, 0x00,
    0x6e, 0x00, 0x67, 0x00,
    0x00, 0x00
    0x04, 0x00,                       // wPropertyDataLength – 4 bytes
    0x02, 0x00, 0x00, 0x00  // PropertyData - SPEAKER_FRONT_RIGHT

    //
    // Microsoft OS 2.0 Registry Value Feature Descriptor
    //
    0x2A, 0x00,             // bLength - 42 bytes
    0x04, 0x00,             // wDescriptorType – 5 for Registry Property
    0x04, 0x00,             // wPropertyDataType - 4 for REG_DWORD
    0x1C, 0x00,             // wPropertyNameLength – 28 bytes
    0x54, 0x00, 0x30, 0x00, // Property Name - "T01_J01_Color"
    0x31, 0x00, 0x5f, 0x00,
    0x4a, 0x00, 0x30, 0x00,
    0x31, 0x00, 0x5f, 0x00,
    0x43, 0x00, 0x6f, 0x00,
    0x6c, 0x00, 0x6f, 0x00,
    0x72, 0x00, 0x00, 0x00,
    0x04, 0x00,             // wPropertyDataLength – 4 bytes
    0x00, 0x00, 0xff, 0x00  // PropertyData - 0xff0000 - RED }

Resolução de problemas

Se o driver não iniciar, o log de eventos do sistema deverá ser verificado. O driver registra eventos que indicam o motivo da falha. Da mesma forma, os logs de áudio podem ser coletados manualmente seguindo as etapas descritas no artigo de blog de Matthew van Eerde, Coletando Logs de Áudio à Moda Antiga. Se a falha puder indicar um problema de driver, denuncie-o usando o Hub de Comentários descrito abaixo e inclua os logs.

Para obter informações sobre como ler logs para o driver de classe USB Audio 2.0 usando arquivos TMF complementares, consulte Relatar problemas, com logs, e sugerir recursos, com o Hub de Comentários no blog de Matthew van Eerde. Para obter informações gerais sobre como trabalhar com arquivos TMF, consulte Exibindo um log de rastreamento com um arquivo TMF.

Para obter informações sobre o erro "Serviços de áudio não estão respondendo" e o dispositivo de áudio USB não funcionar no Windows 10 versão 1703, consulte USB Audio Não Está Reproduzindo.

Hub de Feedback

Se você tiver um problema com esse driver, colete logs de áudio e siga as etapas descritas em Relatar problemas, com logs, e sugerir recursos, com o Hub de Comentários para nos informar.

Desenvolvimento de driver

Esse driver da classe USB Audio 2.0 foi desenvolvido pelo Thesycon e tem suporte da Microsoft.

Consulte também