Share 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 identificará no gerenciador de dispositivos como "Dispositivo usb de classe de áudio 2". Esse nome será substituído por uma cadeia de caracteres de produto USB, se estiver disponível.

O driver é habilitado automaticamente quando um dispositivo compatível é anexado ao sistema. No entanto, se um driver de terceiros existir no sistema ou 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 Áudio USB e são referenciadas neste artigo.

  • USB-2 refere-se à Especificação universal do barramento serial, 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, especificações de teste e 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 em um formato desconhecido, será ignorada.

Formatos do tipo I (FMT-2 2.3.1):

  • Formato PCM com 8,32 bits por exemplo (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 em hardware usb audio 2.0 compatível. 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 origem de relógio único. 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 ponto de extremidade (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 comentários explícitos. Um ponto de extremidade de comentários 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 encaminhamento de feed. Se esse ponto de extremidade estiver presente na configuração alternativa, ele será ignorado. O driver lida com o fluxo adaptável IN da mesma forma que um fluxo IN assíncrono.

O tamanho dos pacotes isócronos criados pelo dispositivo deve estar dentro dos limites especificados na seção 2.3.1.1 do FMT-2.0. Isso significa que o desvio do tamanho real do pacote do tamanho nominal não deve exceder +/- um slot de áudio (slot de áudio = exemplos 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 nenhuma interface de streaming não tem suporte.

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 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 em hardware usb audio 2.0 compatível.

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 comentários. 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 do 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 salvar a 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 valores wMaxPacketSize diferentes no descritor de ponto de extremidade de dados isocrono. Para uma determinada taxa de exemplo, o driver seleciona a configuração alternativa com o menor wMaxPacketSize que pode atender aos requisitos de taxa de dados.

Descritor de tipo I de tipo de formato

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

As restrições a seguir se aplicam:

Formatar Tamanho do subslot Resolução de bits
Formato de PCM do tipo I: 1 <= bSubslotSize <= 4 8 <= bBitResolution <= 32
Digite formato I PCM8: bSubslotSize == 1 bBitResolution == 8
Tipo I IEEE_FLOAT formato: bSubslotSize == 4 bBitResolution == 32
Formatos de IEC61937 do 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 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 Control GET CUR SET CUR INTERVALO GET 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 numerador x
Controle denominador x
Terminal Controle do conector x x
Unidade do Mixer Controle de mixer x x x
Unidade seletora Controle seletor x x
Unidade de Recursos Ativar mudo do controle 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 ADC-2 5.2.5.1.

No mínimo, uma Entidade de Origem de Relógio deve implementar as solicitações GET RANGE e GET CUR do Controle de Frequência de Amostragem (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 subrange 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 para a respectiva frequência e RES como zero. Subranges individuais não devem se sobrepor. Se um subrange se sobrepor a anterior, ele será ignorado pelo driver.

Uma entidade de origem de relógio que implementa apenas uma única frequência fixa não precisa implementar o SET CUR do Controle de Frequência de Amostragem. 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 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 recursos

Para obter detalhes sobre essa especificação, consulte 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 master para Mudo ou Volume, o driver usará os controles de canal único e ignorará o controle master.

Informações adicionais para OEM e IHVs

Os OEMs e IHVs devem testar seus dispositivos existentes e novos no driver in-box fornecido.

Não há nenhuma personalização de parceiro específica associada ao driver usb audio 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 acima) enumerarão a função MIDI como um dispositivo de várias funções separado com usbaudio.sys (driver USB Audio 1.0) carregado.

O driver de classe USB Audio 1.0 registra essa ID compatível com wdma_usb.inf.

USB\Class_01

E tem essas 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 driver de terceiros fornecidos por IHV, esses drivers continuarão a ser preferenciais para seus dispositivos em vez do nosso driver interno, a menos que atualizem o driver para substituir explicitamente esse comportamento e usar o driver in-box.

Descrições do Registro de Tomada de Áudio

A partir do Windows 10 versão 1703, os IHVs que criam dispositivos USB Audio Class 2.0 com uma ou mais tomadas têm a capacidade de descrever essas tomadas para o driver da Classe de Áudio 2.0 in-box. O driver in-box usa as informações de tomada fornecidas ao lidar com o 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 de informações de tomada 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 a tomada de áudio, consulte KSJACK_DESCRIPTION estrutura.

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

  • Usando INFs personalizados, que encapsulam o INF in-box para a finalidade de definir esses valores.

  • Diretamente pelo dispositivo de hardware por meio de um Descritor do sistema operacional 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 de SO da 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 }

Solução de problemas

Se o driver não for iniciado, 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 log da Web de Matthew van Eerde, Coletando logs de áudio à moda antiga. Se a falha puder indicar um problema de driver, relate-o usando o Hub de Feedback 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 Feedback no log da Web 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 funciona no Windows 10 versão 1703, consulte Áudio USB não está sendo reproduzido.

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 Feedback para chamar nossa atenção.

Desenvolvimento de drivers

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

Confira também