Áudio Bluetooth de Baixa Energia

Este artigo fornece uma visão geral do Bluetooth LE Audio introduzido no Windows 11 versão 22H2 (KB5026446).

Introdução

O Bluetooth LE Audio permite transmitir áudio unicast ou de difusão para dispositivos Bluetooth LE por meio de um transporte isócrono. A partir da versão 5.3 da especificação principal do Bluetooth, não há uma HCI (interface do controlador de host) definida padrão para que as plataformas host enviem e recebam dados isocronos de e para o controlador Bluetooth. Este documento define o VSAP (caminho de áudio específico) do fornecedor bluetooth do Windows para permitir que as plataformas usem soluções específicas do fornecedor para habilitar o streaming de áudio Bluetooth LE. A interface de software VSAP usa as extensões de classe de áudio (ACX) do Windows e mais propriedades de interface definidas neste documento.

Terminologia e pré-requisitos

Além dos termos definidos nesta tabela, este documento também faz referência aos termos definidos pelas extensões de classe de áudio do Windows.

Este artigo pressupõe familiaridade com os termos definidos anteriormente e os seguintes comandos HCI definidos na especificação do Bluetooth Core:

• Comandos do controlador local
  • HCI_Read_Local_Supported_Codecs (v2)
  • HCI_Read_Local_Supported_Codec_Capabilities
  • HCI_LE_Setup_ISO_Data_Path
  • HCI_LE_Remove_ISO_Data_Path
  • Configurar_Caminho_de_Dados_HCI
• Comandos de streaming Unicast
  • HCI_LE_Set_CIG_Parameters
  • HCI_LE_Create_CIS
  • HCI_LE_Remove_CIG
• Comandos de streaming de transmissão
  • HCI_LE_Create_BIG
  • HCI_LE_Terminate_BIG
  • HCI_LE_BIG_Create_Sync
  • HCI_LE_BIG_Terminate_Sync
  • HCI_LE_Set_Periodic_Advertising_Parameters
  • HCI_LE_Set_Periodic_Advertising_Data
  • HCI_LE_Set_Periodic_Advertising_Enable
  • HCI_LE_Periodic_Advertising_Create_Sync
  • HCI_LE_Periodic_Advertising_Create_Sync_Cancel
  • HCI_LE_Periodic_Advertising_Terminate_Sync
  • HCI_LE_Set_Periodic_Advertising_Receive_Enable
  • HCI_LE_Periodic_Advertising_Report
  • HCI_LE_BIGInfo_Advertising_Report
  • HCI_LE_Read_Periodic_Advertiser_List_Size
  • HCI_LE_Add_Device_To_Periodic_Advertiser_List
  • HCI_LE_Remove_Device_From_Periodic_Advertiser_List
  • HCI_LE_Clear_Periodic_Advertiser_List
  • HCI_LE_Periodic_Advertising_Set_Info_Transfer
  • HCI_LE_Periodic_Advertising_Sync_Transfer
  • HCI_LE_Set_Default_Periodic_Advertising_Sync_Transfer_Parameters
  • HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Parameters

O VSAP de áudio Bluetooth LE requer que os drivers de áudio usem o framework ACX. A adoção do ACX para Bluetooth LE Audio oferece várias vantagens, como:

• Dá suporte ao modelo de driver de áudio preferencial para Windows daqui para frente.
• Usa o suporte nativo do ACX para soluções de áudio de multicamadas sem exigir uma DDI dedicada entre controladores.
• Não requer drivers de áudio IHV para retransmitir solicitações do sistema de áudio para a pilha Bluetooth. Em vez disso, o ACX pode enviar solicitações diretamente para a pilha Bluetooth por meio do circuito de perfil.

Arquitetura

Definições

Os componentes a seguir estão envolvidos nas diferentes variantes de arquitetura do VSAP.

Estrutura ACX do Windows

Esse componente habilita o suporte para um ponto de extremidade de áudio multi-camadas. Para o Áudio LE Bluetooth, os componentes de software que compõem um ponto de extremidade de áudio são a pilha de driver de áudio específica do fornecedor e o perfil de Áudio LE Bluetooth do Windows.

Pilha de drivers de áudio específica para fornecedor

Esse componente específico do fornecedor é responsável por enviar e receber dados bluetooth LE Audio de e para um controlador Bluetooth por meio de uma interface de áudio definida pelo fornecedor. Ele deve consistir, no mínimo, em um driver de streaming ACX para gerenciar os dados de áudio de entrada e saída. Mais drivers ACX poderão ser incluídos se forem partes necessárias do ponto de extremidade de áudio ACX de vários circuitos. Esse componente também é conhecido como o driver de streaming do ACX IHV neste documento.

Perfil de Áudio Bluetooth LE do Windows

Esse componente contém a implementação do perfil de áudio básico (BAP), perfil de controle de volume e perfil de controle de microfone. Ele é responsável por criar o controle ACXCIRCUIT para cada dispositivo Bluetooth LE Audio ou conjunto de dispositivos emparelhados com o Windows. Ele também relata formatos de áudio do dispositivo remoto e do controlador Bluetooth e gerencia o estado de canais e grupos isocronos.

Pilha principal de Bluetooth do Windows

Esse componente fornece uma interface para permitir que o Perfil de Áudio LE bluetooth do Windows consulte os recursos de codec com suporte do controlador Bluetooth local e gerencie o estado de canais e grupos isocronos.

Codec LC3

Esse subcomponente se traduz entre áudio LC3 compactado e áudio PCM. Ele deve dar suporte a recursos de codificação e decodificação. O codec LC3 pode ser implementado no software como parte da pilha do VSAP (driver de áudio) específico do fornecedor. Como alternativa, ele pode ser implementado em hardware como parte do DSP de áudio ou controlador Bluetooth. O diagrama menciona LC3 pelo nome, pois é o codec padrão compatível com o SIG Bluetooth. Codecs futuros e codecs específicos do fornecedor compatíveis com o Windows também podem ser incorporados à arquitetura de maneira semelhante.

Variantes de arquitetura

A arquitetura VSAP de áudio Bluetooth LE dá suporte a diferentes variantes para streaming.

1. Sideband Bluetooth LE Áudio streaming sem descarregamento de áudio
2. Sideband Bluetooth LE Áudio streaming com descarregamento de áudio
3. Streaming de áudio inband Bluetooth LE específico do fornecedor

Nos diagramas a seguir, os componentes sombreados são fornecidos pelo IHV e os componentes sem sombra são fornecidos pelo sistema operacional.

Arquitetura de áudio DE LE bluetooth de sideband sem descarregamento de áudio

Uma arquitetura de sideband usa uma interface de áudio específica do fabricante, permitindo que a pilha de drivers de áudio envie e receba dados de áudio para o controlador Bluetooth. Esse caminho de dados é separado do caminho de dados HCI usado para outros dados Bluetooth, como mensagens de sinalização entre o cliente unicast e o servidor unicast remoto. O diagrama a seguir modela uma arquitetura de sideband em que o codec LC3 está hospedado no controlador Bluetooth. Também é válido ter o codec LC3 hospedado como parte da Pilha de Drivers de Áudio Específica do Fornecedor para codificação e decodificação por software. Nesse caso, o áudio enviado para o controlador Bluetooth seria formatado como quadros de áudio LC3 em vez de áudio PCM.

O diagrama a seguir mostra uma arquitetura de áudio Bluetooth LE de banda lateral com um codec LC3 no controlador Bluetooth.

O diagrama a seguir mostra uma arquitetura de Bluetooth LE Audio de banda lateral, com um codec LC3 na pilha do driver de áudio.

Arquitetura de áudio Bluetooth LE de banda lateral com offload de áudio

Uma arquitetura de banda lateral com deslocamento de áudio inclui um componente de hardware DSP de áudio para fornecer uma solução Bluetooth LE para streaming de áudio com benefícios em termos de economia de energia. Os diagramas a seguir demonstram uma possível arquitetura com o codec LC3 no controlador Bluetooth e o codec no DSP de áudio.

O diagrama a seguir mostra um Bluetooth LE Audio sideband com arquitetura de descarregamento de áudio e um codec LC3 no controlador Bluetooth.

O diagrama a seguir mostra uma banda lateral Bluetooth LE Audio com arquitetura de offload de áudio, utilizando um codec LC3 no DSP de áudio.

Arquitetura de Áudio Bluetooth LE em Banda Específica do Fornecedor

A arquitetura inband do VSAP permite que um pipeline personalizado envie e receba dados de Bluetooth LE Audio da pilha de driver de áudio específica do fornecedor para o HCI do controlador Bluetooth. Essa arquitetura inclui um novo componente, o "Componente de mesclagem ISO do IHV". Esse componente é responsável por gerenciar o controle de fluxo para os dados ISO. Ele também compartilhará o controle de fluxo de comando HCI com o Windows Bluetooth Core Stack se precisar enviar comandos HCI.

O diagrama a seguir mostra uma arquitetura de áudio Bluetooth LE de banda de entrada específica do fornecedor.

Design detalhado

Requisitos de formato de áudio

KSAUDIO_PACKETSIZE_CONSTRAINTS2

Drivers de áudio ACX IHV são necessários para dar suporte à propriedade KSAUDIO_PACKETSIZE_CONSTRAINTS2. O suporte a essa propriedade reduz o tempo entre adicionar um dispositivo de áudio BLUETOOTH LE ao Windows e o dispositivo de áudio ficar disponível para aplicativos para streaming.

Durações do quadro de áudio

Perfis de áudio Bluetooth LE permitem que implementações ofereçam suporte ao streaming de áudio com durações de quadro de 7,5 milissegundos ou 10 milissegundos. O Windows requer codecs fornecidos por IHVs para dar suporte a ambas as durações de quadro. Esse requisito garante a interoperabilidade com dispositivos acessórios Bluetooth LE Audio e coexistência de qualidade com outros dispositivos Bluetooth LE conectados ao sistema.

Definições do modo de processamento de sinal

O Bluetooth LE Audio dá suporte a uma ampla gama de formatos de streaming para dar suporte a diferentes cenários de usuário. As especificações BAP e TMAP definem formatos com suporte obrigatório para certificação. O Windows aplica modos de processamento de sinal de áudio para correlacionar o formato a ser usado com o cenário que o sistema está executando. Os drivers de áudio que dão suporte ao Bluetooth LE Audio devem indicar suporte para os modos e formatos de processamento de sinal na tabela a seguir. Além disso, o Bluetooth LE Audio não dá suporte ao modo de processamento de sinal bruto, portanto, os drivers de áudio não devem anunciar nenhum formato com suporte para esse modo.

Formatos de áudio de fluxo de renderização unicast e modos de processamento de sinal

O Bluetooth LE Audio requer que os formatos de áudio de renderização unicast sejam declarados para os seguintes modos de processamento de sinal:

• Padrão (AUDIO_SIGNALPROCESSINGMODE_DEFAULT)
  • Esse modo é usado para cenários de renderização unidirecional, como reprodução de música, notificações e áudio de videogame.
• Comunicações (AUDIO_SIGNALPROCESSINGMODE_COMMUNICATIONS)
  • Esse modo é usado para cenários bidirecionais, como chamadas de voz.

As tabelas a seguir são listas de formatos simétricos para cada caso de uso e modo de processamento de sinal. O suporte ao formato assimétrico é definido no estéreo super wideband para cenários de voz.

Os formatos de áudio são ordenados dos mais preferenciais aos menos preferenciais.

Sons do sistema, reprodução de música e áudio de videogame quando conectado a um dispositivo estéreo ou conjunto coordenado de dispositivos

Modo de processamento de sinal: padrão

Sons do sistema, reprodução de música e áudio de videogame quando conectado a um único membro de um conjunto coordenado (earbud único ou aparelho auditivo)

Modo de processamento de sinal: padrão

Renderizar gravador de voz, chamadas VoIP ou áudio de jogos eletrônicos com chat por voz

Modo de processamento de sinal: comunicações

Formatos de áudio de fluxo de captura unicast e modos de processamento de sinal

O Bluetooth LE Audio requer que os formatos de áudio de captura unicast sejam declarados para o modo de processamento de sinal Padrão (AUDIO_SIGNALPROCESSINGMODE_DEFAULT). A lista de formatos de captura com suporte está na tabela a seguir.

Os formatos de áudio são ordenados dos mais preferenciais aos menos preferenciais.

Capturar gravador de voz, chamadas VOIP ou áudio de videogame com chat de voz

Modo de processamento de sinal: padrão

Modos de processamento de sinal de áudio de transmissão

O áudio LE bluetooth do Windows requer que os formatos de áudio de origem de difusão (renderização) sejam declarados para o modo de processamento de sinal Padrão (AUDIO_SIGNALPROCESSINGMODE_DEFAULT).

O Áudio LE bluetooth do Windows requer que os formatos de áudio do coletor de difusão (captura) sejam declarados para o modo de processamento de sinal Padrão (AUDIO_SIGNALPROCESSINGMODE_DEFAULT).

A lista completa a seguir de formatos com suporte necessários é idêntica para ambas as funções.

Fluxo de transmissão estéreo para sons do sistema, reprodução de música e áudio de videogame

Modo de processamento de sinal: padrão

Fluxo de transmissão mono para sons do sistema, reprodução de música e áudio de videogame

Modo de processamento de sinal: padrão

Configurações e topologias de fluxo definidas

Configurações somente de renderização unicast

Configuração básica do perfil de áudio 1

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos mono. O único dispositivo pode ser um dispositivo autônomo ou um único membro conectado de um conjunto coordenado.

Configuração básica do perfil de áudio 4

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos estéreo. O dispositivo de áudio é capaz de processar dois canais de áudio em um único CIS.

Configuração básica do perfil de áudio 6(i)

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos estéreo. O dispositivo de áudio só é capaz de processar um canal de áudio em cada uma das duas CISs

Configuração básica do perfil de áudio 6(ii)

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um conjunto coordenado de dispositivos de áudio. O conjunto é capaz de processar dois canais de áudio com cada membro processando um único canal.

Configurações bidirecionais unicast

As configurações bidirecionais são usadas quando o perfil bluetooth LE Audio detecta que um aplicativo pretende criar um fluxo de captura e renderização para um dispositivo remoto ou um conjunto de dispositivos. Os aplicativos controlam a captura e renderizam fluxos separadamente. Portanto, drivers de áudio IHV e controladores Bluetooth permitirão que o áudio flua em uma única direção de um CIS bidirecional após o provisionamento. Esse provisionamento usa os comandos HCI Configure Data Path e LE Setup ISO Data Path.

Configuração básica do perfil de áudio 3

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio com um fluxo mono bidirecional estabelecido em um único CIS.

Configuração básica do perfil de áudio 8(i)

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos de renderização estéreo e fluxos de captura mono. O dispositivo é capaz de processar um canal de áudio em um único CIS para uma direção específica.

Configuração básica do perfil de áudio 8(ii)

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um conjunto coordenado de dispositivos de áudio. Cada membro do conjunto está recebendo um canal de áudio de renderização. Um único membro de conjunto tem um fluxo de captura estabelecido. O membro definido com o fluxo de captura é o primeiro membro definido que se conecta ao computador que também dá suporte a fluxos de captura.

Configurações somente de captura unicast

Configuração básica do perfil de áudio 2

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos de captura mono.

Configuração básica do perfil de áudio 9(i)

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um único dispositivo de áudio que dá suporte ao envio de dados de áudio estéreo. O dispositivo é capaz de codificar um canal de áudio em um único CIS.

Configuração básica do perfil de áudio 9(ii)

O computador está conectado a um único dispositivo de áudio que dá suporte a fluxos de captura mono.

A configuração de áudio a seguir é definida na tabela 4.1 da especificação do BAP Bluetooth

O computador está conectado a um conjunto de dispositivos de áudio. Cada membro do conjunto envia um canal de áudio para o computador.

Se o dispositivo remoto ou o conjunto de dispositivos der suporte a áudio bidirecional, a configuração de um fluxo somente de captura será a mesma do que para o bidirecional. Essa configuração permite transições de cenários de captura somente para cenários bidirecionais sem a necessidade de recriar os fluxos.

Configurações de origem de difusão

Configuração básica do perfil de áudio 12

A configuração de áudio a seguir é definida na tabela 4.2 da especificação do BAP Bluetooth

O computador está transmitindo um canal de áudio mono.

Configuração básica do perfil de áudio 13

A configuração de áudio a seguir é definida na tabela 4.2 da especificação do BAP Bluetooth

O computador está transmitindo áudio estéreo com cada canal transmitindo em seu próprio BIS.

Estruturas de dados

Propriedades da interface bluetooth LE Audio definidas pela Microsoft

Propriedades de criação de fluxo de dados

As propriedades a seguir são compartilhadas entre a pilha de driver de áudio específica do fornecedor e o Perfil de Áudio BLUETOOTH LE por meio dos DDIsACXOBJECTBAG. Essas propriedades informam as decisões sobre a criação e a configuração do ponto de extremidade de fluxo, conforme mostrado no cenário de Criação de Fluxo .

BluetoothLEAudio_CodecCapabilities

O driver de áudio define essa propriedade para indicar suporte para recursos de streaming de áudio com suporte no DSP de áudio ou driver de áudio. O valor da propriedade é definido usando o DDI AcxObjectBagAddBlob e o formato do valor é o mesmo que um registro PAC definido na especificação PACS.

O perfil de áudio Bluetooth LE do Windows lê a propriedade para determinar as possíveis configurações de codec e a composição do fluxo a ser usada.

Os valores de campo são definidos nas tabelas 3.2 e 3.4 da especificação PACS.

Bluetooth_DatapathID

O driver de áudio define essa propriedade para indicar a ID do caminho de dados usada como parâmetro para os comandos HCI_LE_Setup_ISO_Data_Path e HCI_Configure_Data_Path. O valor da propriedade é definido usando a DDI AcxObjectBagAddUI8 .

O perfil Bluetooth LE Audio lê e usa essa propriedade como parâmetro nos comandos HCI_Configure_Data_Path e HCI_LE_Setup_ISO_Data_Path. Este ID é aplicado a todos os fluxos isócronos criados para o ACXSTREAM associado ao conjunto de objetos. Para atribuir uma ID de caminho de dados diferente para cada conexão de fluxo, use KSPROPERTY_BtLeAudio_DATAPATH_ID em seus drivers de áudio.

Se o driver de áudio não definir essa propriedade, o sistema operacional usará o valor 1 como o parâmetro para os comandos HCI.

Bluetooth_DatapathConfiguration

O driver de áudio define essa propriedade para fornecer configurações específicas do fornecedor para o controlador Bluetooth por meio do comando HCI_Configure_Data_Path. Ele não deve ser maior que 255 bytes, que é o maior conteúdo que um controlador Bluetooth aceita para um comando HCI. O valor da propriedade é definido usando a DDI AcxObjectBagAddBlob . Essa configuração se aplica a todas as IDs de caminho de dados definidas pelo driver de áudio. Para atribuir uma configuração de caminho de dados diferente para cada ID de datapath, use KSPROPERTY_BtLeAudio_DATAPATH_CONFIG em seus drivers de áudio.

Bluetooth_RequiresHciTransportInD0ForStreaming

O driver de áudio define essa propriedade para indicar que o controlador Bluetooth não deve fazer a transição para um estado de baixa potência enquanto um fluxo de áudio estiver ativo. O valor da propriedade é definido usando a DDI AcxObjectBagAddUI8 .

BluetoothLEAudio_CodecConfiguration

Essa propriedade deve ser definida pelo perfil Bluetooth LE Audio usando o DDI AcxObjectBagAddBlob após a configuração do codec ser feita com um dispositivo de áudio. A estrutura do valor é:

Os valores de campo são derivados da tabela 4.3 da Especificação do Serviço de Controle de Fluxo de Áudio Bluetooth.

A pilha de drivers de áudio específica do fornecedor deve ler esta propriedade se o codec LC3 estiver no driver de streaming ACX ou no DSP de áudio.

BluetoothLEAudio_StreamConnectionHandles

Essa propriedade deve ser definida pelo perfil de áudio BLUETOOTH LE para informar o driver de áudio da lista de identificadores BIS ou CIS criados para um BIG ou CIG. A ordem dos identificadores corresponde à ordem retornada pelo controlador Bluetooth ao comando HCI LE_Set_CIG_Parameters ou ao evento HCI LE_Create_BIG_Complete. A estrutura do valor é:

Propriedades de KS de áudio do Bluetooth LE

As propriedades KS permitem que o driver de áudio ACX IHV defina ou atualize as configurações de fluxo de áudio após a criação do fluxo. Esse cenário é útil para drivers de áudio definirem as configurações com base nas propriedades definidas pelo circuito de perfil Bluetooth no procedimento create stream.

Definições

#define STATIC_KSPROPSETID_BtLeAudio\
    0x1159b79, 0xea6, 0x4923, 0x80, 0xf5, 0x32, 0x58, 0xd1, 0xfd, 0x91, 0x56
DEFINE_GUIDSTRUCT("01159B79-0EA6-4923-80F5-3258D1FD9156", KSPROPSETID_BtLeAudio);
#define KSPROPSETID_BtLeAudio DEFINE_GUIDNAMED(KSPROPSETID_BtLeAudio)

typedef enum {
    KSPROPERTY_BtLeAudio_DATAPATH_ID,
    KSPROPERTY_BtLeAudio_DATAPATH_CONFIG,
} ksproperty_btleaudio;

KSPROPERTY_BtLeAudio_DATAPATH_ID

Esse KSProperty permite que drivers de áudio ACX IHV definam ou atualizem o valor definido por Bluetooth_DatapathID após a invocação do retorno de chamada de fluxo de criação. Essa propriedade também permite que drivers de áudio IHV atribuam uma ID de caminho de dados diferente para cada entrada de configuração de codec em BluetoothLEAudio_CodecConfiguration. O valor dessa propriedade deve ser definido como um único valor de byte para representar a ID do caminho de dados usada para todas as configurações de codec ou n bytes em que n é igual ao valor de Contagem de Configuração definido na propriedade BluetoothLEAudio_CodecConfiguration. Se o valor contiver várias IDs de caminho de dados, a ordem das IDs será usada para a configuração do codec, conforme ordenado na propriedade BluetoothLEAudio_CodecConfiguration.

KSPROPERTY_BtLeAudio_DATAPATH_CONFIG

Esse KSProperty permite que os drivers de áudio ACX IHV definam ou atualizem a configuração do caminho de dados, conforme definido em Bluetooth_DatapathConfiguration. O KSProperty deve ser enviado pelo driver de áudio para o perfil Bluetooth antes que o retorno de chamada de fluxo de áudio inicial seja invocado. Essa propriedade pode ser usada para definir uma única configuração para todos os caminhos de dados em uma única direção ou para definir uma configuração de caminho de dados específica para cada entrada de configuração de codec definida em BluetoothLEAudio_CodecConfiguration. Se o valor contiver várias configurações de caminho de dados, a ordem das configurações será usada para a entrada de configuração de codec, conforme ordenado na propriedade BluetoothLEAudio_CodecConfiguration. O número de configurações de codec deve ser igual ao número de IDs de caminho de dados definidas por KSPROPERTY_BtLeAudio_DATAPATH_ID ou Bluetooth_DatapathID.

Interfaces

IDs de associação de modelo de ponto de extremidade de áudio

Usado pela fábrica de circuitos ACX no driver de áudio para identificar quando um circuito ACX para um dispositivo Bluetooth emparelhado é criado.

As seguintes IDs de componente são usadas para criar circuitos de áudio BLUETOOTH LE:

// {5C52FDB5-722A-4AB7-A342-70163B7E9B5C}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_RENDER_COMPONENT_ID,
0x5c52fdb5, 0x722a, 0x4ab7, 0xa3, 0x42, 0x70, 0x16, 0x3b, 0x7e, 0x9b, 0x5c);

// {1DFF2EE3-AE89-441C-BDE3-24F885C55DF8}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_CAPTURE_COMPONENT_ID,
0x1dff2ee3, 0xae89, 0x441c, 0xbd, 0xe3, 0x24, 0xf8, 0x85, 0xc5, 0x5d, 0xf8);

Interface de suporte do Bluetooth LE Audio

Usado pela pilha do driver de áudio para indicar que está disponível para streaming de Bluetooth LE Audio. Monitoramento no nível do serviço de Áudio Bluetooth do Windows para essa interface e aguarde até que seja publicada antes de habilitar o suporte a áudio LE.

As seguintes IDs de interface são usadas para publicar a interface de suporte do Bluetooth LE Audio:

// {BA02FA1B-0FD0-4A0F-A748-4FAE2E2D2F67}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
0xba02fa1b, 0x0fd0, 0x4a0f, 0xa7, 0x48, 0x4f, 0xae, 0x2e, 0x2d, 0x2f, 0x67);

Sequências comuns

As sequências a seguir são executadas para cenários de áudio LE unicast e de transmissão.

Inicialização do driver de áudio

Quando o driver de streaming do ACX IHV é carregado e determina que ele dá suporte ao streaming de áudio Bluetooth LE, ele deve mostrar suporte para a tecnologia criando um objeto ACXFACTORYCIRCUIT e registrando-se para associações de modelo Bluetooth com ACX usando as IDs definidas em IDs de associação de modelo de ponto de extremidade de áudio.

Sequências de áudio Unicast

Criação de ponto de extremidade

1. Quando um dispositivo le audio é emparelhado com o sistema, o Perfil de Áudio LE Bluetooth:

   1. Lê as capacidades de áudio publicadas do dispositivo remoto.
   2. Descobre as capacidades suportadas do controlador enviando os comandos HCI_Read_Local_Support_Codecs [v2] e HCI_Read_Local_Supported_Codec_Capabilities.
   3. Cria um ACXCIRCUIT com os formatos com suporte definidos com base nos recursos codec compatíveis com o controlador Bluetooth e o dispositivo de áudio remoto. Se o controlador não oferecer suporte a nenhum codec porque o suporte a codec está no DSP de áudio ou no driver de áudio, os formatos suportados são definidos pelos formatos suportados pelo dispositivo de áudio remoto.

2. Depois que o ACXCIRCUIT é criado, o ACX solicita à fábrica de circuitos do driver de streaming ACX IHV a criação de um ACXCIRCUIT para processamento de fluxo.

3. Quando uma solicitação para criar um circuito é recebida, o driver de streaming ACX IHV:

   1. Cria objetos ACXCIRCUIT, ACXPIN, ACXOBJECTBAG e ACXSTREAMBRIDGE .
   2. Se o codec LC3 ou o codec específico do fornecedor estiver hospedado no driver de áudio ou DSP, o driver de streaming ACX IHV definirá a propriedade BluetoothLEAudio_CodecCapabilities no ACXOBJECTBAG.
   3. O driver de streaming do ACX IHV pode definir Bluetooth_DatapathID ou Bluetooth_DatapathConfiguration no ACXOBJECTBAG se ele for conhecido no momento.

4. Depois que ambos os circuitos são criados, o ACX invoca o retorno de chamada EvtAcxPinConnected no pino de ponte do driver ACX IHV.

5. Quando o retorno de chamada EvtAcxPinConnected é invocado , o driver de streaming ACX IHV:

   1. Recupera o pino de interconexão do circuito de perfil usando as APIs AcxTarget... para obter os formatos suportados pelo circuito de perfil.
   2. Itera através da lista de ACXDATAFORMATs definidos pelo circuito de perfil. Se o codec de áudio Bluetooth estiver hospedado no DSP de áudio ou driver de áudio, o driver de áudio IHV atualizará seus ACXDATAFORMATcom os formatos compatíveis com o codec e o circuito de perfil. Caso contrário, todos os formatos serão copiados para o pin de host do driver de streaming DO ACX IHV.
   3. Define a lista de formatos atualizada no pino de ponte se um mecanismo de áudio for criado para streaming de descarregamento.

6. Depois que os formatos são atualizados, o ACX habilita as duas interfaces, criando um ponto de extremidade de áudio.

   

Criação de fluxo

1. Quando um aplicativo solicita a criação de um fluxo de áudio, o ACX invoca os retornos de chamada EvtCircuitCreateStream registrados para cada circuito, começando com o driver de streaming ACX IHV.

2. Quando o retorno de chamada EvtCircuitCreateStream é invocado, o driver de streaming do ACX IHV:

   1. Define ou atualiza as propriedades Bluetooth_DatapathId e Bluetooth_DataPathConfiguration no ACXOBJECTBAG anexado ao ACXSTREAMBRIDGE.
   2. Cria um ACXSTREAM com retornos de chamada definidos para transições de estado de fluxo e processamento de fluxo RT
   3. Criará um elemento de motor de áudio na transmissão se o pipeline de áudio der suporte à transmissão de alívio de carga.
   4. Adiciona o ACXSTREAM à sua ponte de streaming. Isso invoca o retorno de chamada EvtCircuitCreateStream do perfil Bluetooth LE Audio.

3. Quando o retorno de chamada EvtAcxCircuitCreateStream é invocado, o perfil de áudio BLUETOOTH LE:

   1. Salva localmente as propriedades do ACXOBJECTBAG configuradas pelo driver de streaming ACX da IHV para futuros retornos de chamada de transição de fluxo.
   2. Executa a operação Config Codec conforme definido na especificação BAP. Os parâmetros para a operação são derivados do ACXDATAFORMAT especificado no retorno de chamada EvtAcxCircuitCreateStream e dos outros parâmetros de fluxo no ACXOBJECTBAG ou dos recursos de codec oferecidos pelo Controlador Bluetooth.
   3. Aloca recursos de fluxo enviando o comando HCI LE Set CIG Parameters.
   4. Define a propriedade BluetoothLEAudio_StreamConnectionHandles com a lista de identificadores de conexão CIS retornados pelo controlador Bluetooth.
   5. Define a propriedade BluetoothLEAudio_CodecConfiguration no ACXOBJECTBAG com o valor usado para configurar os dispositivos de áudio remotos.

4. Se o driver de streaming DO ACX IHV precisar atualizar sua ID de caminho de dados ou a configuração do caminho de dados com base nos valores do recipiente de objetos definidos pelo perfil, ele poderá invocar as operações do conjunto KSPROPERTY para atualizar o valor armazenado pelo circuito de perfil.

   1. Cria um ACXSTREAM com funções de retorno definidas para transições de estado do fluxo.

   

Transições de estado de fluxo

O ACX decide a ordem do circuito das transições de estado de fluxo com base no fluxo de áudio e se o estado está fazendo a transição para um estado mais ativo ou menos ativo.

• Para fluxos de renderização que vão de um estado menos ativo para um estado mais ativo, o circuito de perfil recebe o evento primeiro, seguido pelo circuito de streaming.
• Para fluxos de renderização que vão de um estado mais ativo para um estado menos ativo, o circuito de streaming recebe o evento primeiro, seguido pelo circuito de perfil. 
• Para fluxos de captura que vão de um estado menos ativo para um estado mais ativo, o circuito de streaming recebe o evento primeiro, seguido pelo circuito de perfil. 
• Para fluxos capturados que vão de um estado mais ativo para um estado menos ativo, o circuito de perfil começa a receber o evento primeiro, seguido pelo circuito de transmissão.

Preparar transmissão

Quando seu retorno de chamada EvtAcxStreamPrepareHardware é invocado, o perfil de áudio BLUETOOTH LE envia a operação QoS de configuração do ASCS para sincronizar as configurações com o dispositivo remoto, se necessário. É possível que a operação de QoS de configuração do ASCS já tenha sido concluída quando o retorno de chamada foi invocado para a outra direção de um fluxo bidirecional.

Quando seu retorno de chamada EvtAcxStreamPrepareHardware é invocado, o driver de streaming IHV ACX aloca os recursos de streaming necessários e inicializa o pipeline de áudio para colocá-lo no estado adquirido.

Iniciar fluxo

Quando seu retorno de chamada EvtAcxStreamRun é invocado, o perfil de áudio BLUETOOTH LE:

1. Aplica os argumentos de configuração do driver de streaming ACX, conforme descrito abaixo, usando o comando HCI_Configure_Data_Path se eles tiverem sido alterados. O Windows Bluetooth Core Stack armazena em cache o buffer de Vendor_Specific_Config para cada par Data_Path_Direction e Data_Path_ID. O comando HCI_Configure_Data_Path é enviado somente quando o Vendor_Specific_Config é alterado para um par de Data_Path_Direction e Data_Path_ID.
   1. Data_Path_Direction é o AudioDirection do circuito de streaming que emite o retorno de chamada EvtAcxStreamRun.
   2. O Data_Path_ID é preenchido com o valor atribuído mais recentemente de uma das seguintes fontes:
      1. Bluetooth_DatapathID no ACXOBJECTBAG anexado ao ACXSTREAMBRIDGE passado para o Perfil de Áudio LE bluetooth do Windows durante o retorno de chamada EvtCircuitCreateStream.
      2. Dados de KSPROPERTY_BtLeAudio_DATAPATH_ID.
   3. Os dados de Vendor_Specific_Config são preenchidos com o valor atribuído mais recentemente de uma das seguintes fontes:
      1. Bluetooth_DatapathConfiguration no ACXOBJECTBAG anexado ao ACXSTREAMBRIDGE passado para o circuito de Perfil de Áudio LE bluetooth do Windows durante o retorno de chamada EvtCircuitCreateStream.
      2. Dados de KSPROPERTY_BtLeAudio_DATAPATH_CONFIG.
2. Envia a operação Habilitar ASCS para os dispositivos remotos.
3. Cria CISes se elas ainda não foram criadas usando o comando HCI_LE_Create_CIS.
4. Se o caminho de dados ainda não estiver configurado, o perfil de áudio BLUETOOTH LE:
   1. Estabelece os caminhos de dados ISO usando o comando HCI_LE_Setup_ISO_Data_Path
      1. Se o driver de streaming ACX IHV definir a propriedade BluetoothLEAudio_CodecCapabilities, o valor do campo Codec_ID em HCI_LE_Setup_ISO_Data_Path deverá ser definido como transparente (0x3) conforme definido nos Números Atribuídos por Bluetooth. Caso contrário, o valor será o mesmo que o ID do Codec usado na operação de configuração do codec na criação do stream.
5. Se o fluxo de áudio for um fluxo de captura, o perfil de áudio BLUETOOTH LE executará a operação pronta para iniciar o receptor BAP.

Quando o retorno de chamada EvtAcxStreamRun é invocado, o driver de streaming ACX do IHV começa a processar dados de áudio provenientes do sistema de áudio do Windows (renderização) ou capturados pelo controlador Bluetooth (captura).

Pausar fluxo

Quando a sua função de retorno de chamada EvtAcxStreamPause é invocada, o perfil de Áudio Bluetooth LE:

1. Executa o procedimento de desabilitação do fluxo unicast do BAP.
2. Remove o caminho de dados ISO usando o comando HCI_LE_Remove_ISO_Data_Path.
3. Executa o procedimento de prontidão para parar o receptor ASCS se o fluxo de áudio for um fluxo unicast de captura.
4. Desconecte CISes se não houver outros fluxos em uso para esse CIS.

Quando o retorno de chamada EvtAcxStreamPause é invocado, o driver de streaming ACX do IHV pausa seu pipeline de processamento de áudio.

Fluxo de lançamentos

Quando seu retorno de chamada EvtAcxStreamReleaseHardware é invocado, o Perfil de Áudio de LE Bluetooth:

1. Envia a operação de versão do ASCS para o dispositivo remoto Bluetooth LE Audio
2. Remove o CIG se todas as CISes estiverem desconectadas.

Quando seu retorno de chamada EvtAcxStreamReleaseHardware é invocado, o driver de streaming ACX do IHV libera seus recursos de pipeline de áudio.

Desconexão de endpoint

O perfil do Windows Bluetooth LE Audio atualiza o estado de conexão de um ponto de extremidade se o dispositivo unicast remoto não tiver uma conexão LE-ACL com o computador ou estiver relatando por meio de seus contextos de áudio disponíveis para PACS que ele não está disponível para streaming. Quando o ponto de extremidade é desconectado, o serviço de áudio do Windows anula qualquer fluxo de áudio ativo para o ponto de extremidade. Isso resulta na pausa do fluxo e nas sequências de liberação ocorrerem.

Controle de volume e função silenciosa

O circuito de streaming ACX do IHV deve incluir elementos de volume e mudo apenas se o driver de streaming exigir um motor de áudio. Ao usar um mecanismo de áudio, os sinalizadores de configuração devem ser definidos como tal:

ACX_AUDIOENGINE_CONFIG audioEngineCfg;
ACX_AUDIOENGINE_CONFIG_INIT(&audioEngineCfg);
…

audioEngineCfg.Flags |= AcxAudioEngineConfigVolumeSecondary; // Use this control only if endpoint doesn't have one.

audioEngineCfg.MuteElement = muteElement;

audioEngineCfg.Flags |= AcxAudioEngineConfigMuteSecondary; // Use this control only if endpoint doesn't have one.

audioEngineCfg.PeakMeterElement = peakmeterElement;

audioEngineCfg.Flags |= AcxAudioEngineConfigPeakMeterSecondary; // Use this control only if endpoint doesn't have one.

Isso é necessário para permitir que os pontos de extremidade Bluetooth LE Audio usem os perfis de controle de volume e microfone definidos pela Bluetooth SIG para alterações de volume e silencioso para pontos de extremidade de áudio unicast.

Se o dispositivo remoto Bluetooth LE Audio não oferecer suporte aos serviços de controle de volume ou microfone, ou se o ponto de extremidade for criado para áudio de transmissão, o volume e os elementos de silenciamento no mecanismo de áudio servirão como alternativa para lidar com as solicitações de alteração do sistema de áudio. O sistema de áudio do Windows lida com alterações em volume e mudo. Se não houver nenhum motor de áudio e qualquer dispositivo remoto não oferecer suporte ao volume ou aos serviços de microfone, ou o ponto de extremidade de áudio for para transmissão de áudio.

Remoção de ponto de extremidade

Um ponto de extremidade de áudio BLUETOOTH LE é removido do sistema quando o circuito de perfil ou o circuito de streaming é destruído. O circuito de perfil pode ser removido quando o emparelhamento do dispositivo unicast remoto é removido do Windows ou o rádio Bluetooth está desabilitado.

1. Quando o perfil de áudio LE bluetooth do Windows remove seu circuito, o ACX desabilita suas interfaces de ponto de extremidade para sinalizar ao serviço de áudio do Windows que o ponto de extremidade deve ser removido.
2. Quando as interfaces são desabilitadas, o serviço de áudio do Windows invalida todos os fluxos ativos para o ponto de extremidade de áudio BLUETOOTH LE, essa operação resulta na pausa de fluxo e liberação de retornos de chamada a serem invocados no circuito de streaming.
3. Para concluir a remoção do ponto de extremidade, o ACX invalida o circuito do driver de streaming ACX do IHV, o que resulta na invocação pelo WDF do retorno de chamada de limpeza do circuito.
4. Quando o callback de limpeza é chamado, o driver de streaming IHV ACX libera o seu circuito.

Bluetooth LE e coexistência de áudio clássico

O Windows deve garantir que apenas áudio clássico ou áudio LE esteja ativo para um dispositivo de áudio Bluetooth emparelhado que dê suporte a ambas as tecnologias. Se o áudio LE estiver ativo, os DDIs de sideband para A2DP e HFP para o dispositivo remoto serão desabilitados e o circuito de perfil será criado para o ponto de extremidade de áudio LE. Se o áudio clássico estiver ativo, os DDIs de sideband para A2DP e HFP para o dispositivo remoto serão habilitados e o circuito de perfil não será criado para o ponto de extremidade de áudio LE.

Gerenciamento de energia

O Bluetooth LE Audio não tem nenhum requisito de gerenciamento de energia ou fluxos fora do que já está definido pelo WDF.

Estéreo de super wideband para cenários de voz

A experiência de áudio Bluetooth de hoje é conveniente, mas tem limitações, especialmente quando comparadas com experiências de áudio com fio. Uma das principais limitações, com consequências voltadas para o usuário, é a queda para o áudio mono sempre que o microfone estiver ativo. Isso impede que experiências como áudio espacial no Teams e outros aplicativos VoIP funcionem e prejudica muito as experiências de jogos envolvendo chat de voz.

O Bluetooth LE Audio fecha a lacuna com fidelidade de áudio aprimorada e latência reduzida adicionando suporte para reprodução estéreo enquanto o microfone está em uso.

Pares de formato de renderização/captura

Uma solução IHV anuncia seu suporte para renderização estéreo com captura mono fornecendo uma lista de pares de formato de renderização/captura, cada um deles consiste em um formato de renderização estéreo e um formato de captura mono que pode ser usado simultaneamente para streaming bidirecional. Um formato de renderização estéreo (ou captura mono) é definido como um par de um Sampling_Frequency (por exemplo, 16/24/32/48 kHz) e um Audio_Channel_Count (por exemplo, 1/2 ch) associado a um codec de áudio específico, que não se limita ao LC3.

Por exemplo, suponha que uma solução IHV dê suporte à renderização estéreo de 16kHz com captura mono de 16kHz e renderização estéreo de 48kHz com captura mono de 24kHz ou 32kHz. Os pares de formato de renderização/captura correspondentes são semelhantes a este:

^{Tabela 3: Pares de formato de renderização/captura de exemplo}

Como um membro de conjunto coordenado pode ingressar ou desativar a qualquer momento, uma solução IHV deve dar suporte à renderização mono com captura mono nas mesmas respectivas frequências de amostragem para cada entrada nos pares de formato. Isso significa que, dado o exemplo na Tabela 3, todos os pares de formato abaixo também devem ter suporte implícito, mesmo que não sejam declarados explicitamente:

^{Tabela 4: Pares de formato de renderização/captura implícitos para a Tabela 3}

A principal diferença entre a Tabela 3 e a Tabela 4 é que o Audio_Channel_Count para cada formato de renderização no último é definido como um (para "renderização mono"); todo o resto permanece o mesmo.

Pares de formato de renderização/captura obrigatórios

A Tabela 5 define a lista de formatos de áudio que todas as soluções IHV darão suporte:

^{Pares de formato de renderização/captura obrigatórios da Tabela 5}

Anúncio de funcionalidades

Dependendo se o controlador Bluetooth dá suporte ao codec de áudio envolvido (padrão para LC3), uma solução IHV anuncia a lista de pares de formato de renderização/captura que ele dá suporte de diferentes maneiras. Especificamente:

• Se o codec estiver no controlador Bluetooth, o controlador e o driver de streaming do ACX IHV anunciarão as listas de pares de formato de forma independente. Se as duas listas discordarem umas das outras, o Windows deverá se cruzar e manter as partes comuns.

• Se o codec não estiver no controlador Bluetooth (por exemplo, ele está no DSP de áudio), somente o driver de streaming ACX IHV será necessário para anunciar a lista de pares de formato. Controlador Bluetooth

Como o Codec_Capability[i] na resposta de um HCI_Read_Local_Supported_Codec_Capabilities não dá suporte a metadados, o controlador Bluetooth é necessário para dar suporte a uma família de IDs de codec específicas da Microsoft (consulte a Tabela 7) de modo que o Windows possa consultar mais recursos codec, por exemplo, a lista de pares de formato de renderização/captura, que não podem ser facilmente transmitidos pela interface HCI existente.

^{ID de codec específica da Microsoft da Tabela 7}

Os escopos dessas IDs de codec específicas da Microsoft são limitados a:

• HCI_Read_Local_Supported_Codecs [v2]
• HCI_Read_Local_Supported_Codec_Capabilities

Por contrato, o Windows não deve usar nenhuma dessas IDs de codec específicas da Microsoft para outros tipos de comandos HCI.

HCI_Read_Local_Supported_Codecs [v2]

O controlador deve anunciar seu suporte para a ID de codec específica da Microsoft por meio de Vendor_Specific_Codec_ID e Vendor_Specific_Codec_Transport:

^{Tabela 8 HCI_Read_Local_Supported_Codec [v2] valor de resposta}

HCI_Read_Local_Supported_Codec_Capabilities

Para consultar todos os recursos de codec específicos do Windows, incluindo a lista de pares de formato de renderização/captura, o Windows chama HCI_Read_Local_Supported_Codec_Capabilities com os seguintes argumentos:

^{Argumentos de comando de HCI_Read_Local_Supported_Codec_Capabilities da Tabela 9}

Ao receber esse comando, o controlador deverá retornar todos os recursos específicos do Windows para o codec especificado pela ID de codec definida pelo fornecedor. Por exemplo, se a ID de codec definida pelo fornecedor estiver definida como 0x0006, o controlador retornará todos os recursos relacionados ao LC3 exigidos pelo Windows.

A resposta para o comando mantém a mesma estrutura de nível superior que a definida pela Especificação do Bluetooth Core:

^{Estrutura de resposta de HCI_Read_Local_Supported_Codec_Capabilities da Tabela 10}

No entanto, a carga de Codec_Capability[i] é diferente daquela definida pelo SIG e é adaptada para Windows.

Atualmente, o único recurso codec definido pelo Windows é Bidirectional_Multichannel_Streaming, que é descrito abaixo.

Bidirectional_Multichannel_Streaming

Ao anunciar Bidirectional_Multichannel_Streaming, o controlador afirma que dá suporte à renderização simultânea de m-channel com captura de n-canal em que m ≥ 1, n ≥ 1 e m + n> 2. (A renderização estéreo com captura mono é efetivamente uma Bidirectional_Multichannel_Streaming com m = 2 e n = 1.)

Esta tabela descreve o formato para Bidirectional_Multichannel_Streaming:

^{Formato de Bidirectional_Multichannel_Streaming da Tabela 11 (comprimento máximo: 11 bytes)}

Channel_Counts

A opção de contagens de bits para renderização/captura é arbitrária – cinco bits são alocados para renderização (para abranger todos os locais de áudio definidos por SIG) e três bits para captura (para minimizar o tamanho da carga HCI).

Por exemplo, o Channel_Counts da Tabela 3 é 0b00000'0001 porque o número de canais de renderização/captura, por exemplo, m e n, são 2 e 1, respectivamente:

^{Tabela 12 Channel_Counts para a Tabela 3}

Por design, todos os recursos com o mesmo par de ID de codec específico da Microsoft e Channel_Counts devem ser agrupados e representados por um único registro Bidirectional_Multichannel_Streaming.

Render_Sampling_Frequencies

O campo Render_Sampling_Frequencies especifica todas as frequências de renderização que podem ser usadas no contexto da estrutura de Bidirectional_Multichannel_Streaming associada.

Por exemplo, o Render_Sampling_Frequencies da Tabela 3 é 0b0000'1001, o que significa que 16kHz e 48kHz podem ser usados como a frequência de amostragem para renderização de dois canais:

^{Tabela 13 Render_Sampling_Frequencies para a Tabela 3}

Capture_Sampling_Frequencies_List[i]

Para cada bit "um" em Render_Sampling_Frequencies, começando do menos significativo para o mais significativo, o controlador deve fornecer uma máscara de bits exclusiva (Capture_Sampling_Frequencies_List[i]) especificando todas as frequências de captura compatíveis com a frequência representada por esse bit de renderização. O controlador não deve fornecer uma máscara de bits Capture_Sampling_Frequencies para nenhum bit "zero" em Render_Sampling_Frequencies.

Por exemplo, as máscaras de bit de captura da Tabela 3 são semelhantes a esta:

// The order matters!
{
    // Capture_Sampling_Frequencies_List[0] for 16kHz dual-channel rendering.
    0b0000'0001, // 16 kHz single-channel capture

    // Do not create a dummy Capture_Sampling_Frequencies_List entry, for example, 0b0000'0000,
    // for 24kHz dual-channel rendering, which is not supported at all.

    // Do not create a dummy Capture_Sampling_Frequencies_List entry, for example, 0b0000'0000,
    // for 32kHz dual-channel rendering, which is not supported at all.

    // Capture_Sampling_Frequencies_List[1] for 48kHz dual-channel rendering.
    0b0000'0110 // Either 24 or 32 kHz single-channel capture
}

Especificamente:

^{Exemplo da Tabela 14 para criar um Capture_Sampling_Frequencies_List[i] para um Render_Sampling_Frequencies}

IHV ACX Streaming Driver

Para dar suporte à renderização estéreo com captura mono, um driver de streaming IHV ACX define a propriedade do dispositivo, BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities, que representa os pares de formato de renderização/captura descritos em 3.11.2, para uma instância da classe de interface do dispositivo, GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE.

A propriedade deve ser disponibilizada imediatamente após a criação da instância da classe de interface do dispositivo e o valor da propriedade permanece constante durante todo o tempo de vida da instância da classe de interface do dispositivo.

A chave de propriedade de BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities é definida como:

DEFINE_DEVPROPKEY(DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
    0xd27ba3a4, 0x1bfe, 0x4374, 0x88, 0x7d, 0xe8, 0xb3, 0xa6, 0xac, 0xe, 0xe9, 2); // DEVPROP_TYPE_BINARY (BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY[])

O tipo de valor de propriedade associado à chave, DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities, é definido como:

typedef struct _BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY
{
    BTH_LE_AUDIO_CODEC_ID CodecId;
    BOOL IsCodecPresent;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT RenderChannelCount;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT CaptureChannelCount;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY RenderSamplingFrequencies;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY CaptureSamplingFrequenciesList[
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_BIT_LENGTH
    ];
} BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY;

Where:

typedef struct _BTH_LE_AUDIO_CODEC_ID
{
    UINT8 CodingFormat;
    UINT16 CompanyId;
    UINT16 VendorCodecId;
} BTH_LE_AUDIO_CODEC_ID;

typedef UINT8 BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT;

typedef enum _BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY :
    UINT8 // Bit flags
{
    // 16 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ = 0x1,

    // 24 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ = 0x2,

    // 32 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ = 0x4,

    // 48 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ = 0x8,

    // A dummy value for indicating a sampling frequency is "not applicable" in the
    // respective context.
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_NONE = 0,

    // All valid sampling frequencies combined.
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_ALL =
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ,
} BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY;

DEFINE_ENUM_FLAG_OPERATORS(BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY);

#define BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_BIT_LENGTH \
    (sizeof(BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY) * 8)

A estrutura BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY segue regras semelhantes, conforme descrito em Bidirectional_Multichannel_Streaming, exceto que:

• O driver de streaming ACX é necessário para definir um sinalizador extra, IsCodecPresent, para indicar se o codec de interesse é conceitualmente parte do driver de streaming ACX. Por exemplo, se o codec estiver no DSP de áudio, IsCodecPresent deverá ser definido como TRUE. Se o codec estiver no controlador Bluetooth, o sinalizador deverá ser definido como FALSE.

• Para renderização m-channel com captura de n-canal, os valores de RenderChannelCount e CaptureChannelCount são m e n, respectivamente. Em outras palavras, RenderChannelCount e CaptureChannelCount indicam o número real de canais de renderização e captura.

• Dado um índice, i, há um mapeamento um-para-um entre o bit i-th menos significativo de RenderSamplingFrequencies e a entrada i-th de CaptureSamplingFrequenciesList. Se o bit i-th de RenderSamplingFrequencies for zero, defina CaptureSamplingFrequenciesList[i] como zero.

O código de exemplo a seguir mostra como criar a interface do dispositivo GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE e define a propriedade de interface do dispositivo BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities:

PAGED_CODE_SEG
NTSTATUS
AdvertiseBluetoothLEAudioSupport(
    WDFDEVICE Device
    )
{
    // Create a device interface with the class,
    // GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE, for the specified WDF device.
    DECLARE_CONST_UNICODE_STRING(
        bluetoothLEAudioSupportInterface, L"BluetoothLEAudioSupport");
    RETURN_NTSTATUS_IF_FAILED(WdfDeviceCreateDeviceInterface(
        Device,
        &GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
        (PUNICODE_STRING)&bluetoothLEAudioSupportInterface));

#pragma region associate BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities with GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE.
    // Advertise bidirectional multichannel streaming support by setting the device
    // interface property, 
    // BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
    // to the newly created device interface.

    // See Table 7 "Microsoft-specific codec ID" in Microsoft Bluetooth LE Audio
    // IHV Specification for reference.
    constexpr BTH_LE_AUDIO_CODEC_ID microsoftLC3CodecId
    {
        0xff, // Vendor-specific
        0x6,  // Microsoft
        0x6,  // LC3
    };

    constexpr BTH_LE_AUDIO_CODEC_ID microsoftCVSDCodecId
    {
        0xff, // Vendor-specific
        0x6,  // Microsoft
        0x2,  // CVSD
    };

    // For readability purpose only
    constexpr auto SamplingFrequency_None = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_NONE;
    constexpr auto SamplingFrequency_16000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ;
    constexpr auto SamplingFrequency_24000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ;
    constexpr auto SamplingFrequency_32000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ;
    constexpr auto SamplingFrequency_48000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ;
    constexpr auto SamplingFrequency_All = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_ALL;

    // Bidirectional multichannel streaming capabilities
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY capabilities[]
    {
        // List of formats supported for 2-channel render with 1-channel capture using
        // the LC3 codec:
        //
        //      Render           Capture
        //   (Freq, #Chan)    (Freq, #Chan)
        //   =============    =============
        //    (16kHz, 2) <---> (16kHz, 1)
        //    ----------       ----------
        //    (24kHz, 2) <---> (16kHz, 1)
        //    (24kHz, 2) <---> (24kHz, 1)
        //    ----------       ----------
        //    (32kHz, 2) <---> (16kHz, 1)
        //    (32kHz, 2) <---> (24kHz, 1)
        //    (32kHz, 2) <---> (32kHz, 1)
        //    ----------       ----------
        //    (48kHz, 2) <---> (16kHz, 1)
        //    (48kHz, 2) <---> (24kHz, 1)
        //    (48kHz, 2) <---> (32kHz, 1)
        //    (48kHz, 2) <---> (48kHz, 1)
        //
        {
            // CodecId
            microsoftLC3CodecId,
            // IsCodecPresent,
            FALSE, // The LC3 codec is in the Bluetooth Controller.
            // RenderChannelCount
            2,
            // CaptureChannelCount
            1,
            // RenderSamplingFrequencies
            SamplingFrequency_All,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 16kHz, 2-channel render
            SamplingFrequency_16000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 24kHz, 2-channel render
            SamplingFrequency_16000Hz | SamplingFrequency_24000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 32kHz, 2-channel render
            SamplingFrequency_16000Hz |
                SamplingFrequency_24000Hz |
                SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 48kHz, 2-channel render
            SamplingFrequency_All,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
        },
        // List of formats supported for 4-channel render with 2-channel capture using
        // the CVSD codec:
        //
        //      Render           Capture
        //   (Freq, #Chan)    (Freq, #Chan)
        //   =============    =============
        //    (16kHz, 4) <---> (16kHz, 2)
        //    ----------       ----------
        //    (32kHz, 4) <---> (16kHz, 2)
        //    (32kHz, 4) <---> (32kHz, 2)
        //
        {
            // CodecId
            microsoftCVSDCodecId,
            // IsCodecPresent,
            TRUE, // The CVSD codec is in the audio DSP.
            // RenderChannelCount
            4,
            // CaptureChannelCount
            2,
            // RenderSamplingFrequencies
            SamplingFrequency_16000Hz | SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 16kHz, 4-channel render
            SamplingFrequency_16000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 24kHz, 4-channel render
            SamplingFrequency_None, // N/A
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 32kHz, 4-channel render
            SamplingFrequency_16000Hz | SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 48kHz, 4-channel render
            SamplingFrequency_None, // N/A
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
        }
    };

    // Call IoSetDeviceInterfacePropertyData to associate the capabilities associated
    // with the DEVPKEY.
    WDFSTRING wdfSymbolicLinkName;
    RETURN_NTSTATUS_IF_FAILED(WdfStringCreate(
        nullptr, WDF_NO_OBJECT_ATTRIBUTES, &wdfSymbolicLinkName));
    auto deleteWdfStringOnExt = scope_exit([wdfSymbolicLinkName]() -> void
    {
        WdfObjectDelete(wdfSymbolicLinkName);
    });

    RETURN_NTSTATUS_IF_FAILED(WdfDeviceRetrieveDeviceInterfaceString(
        Device,
        &GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
        &bluetoothLEAudioSupportInterface,
        wdfSymbolicLinkName));
    
    UNICODE_STRING symbolicLinkName;
    WdfStringGetUnicodeString(wdfSymbolicLinkName, &symbolicLinkName);

    RETURN_NTSTATUS_IF_FAILED(IoSetDeviceInterfacePropertyData(
        &symbolicLinkName,
        &DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
        LOCALE_NEUTRAL,
        PLUGPLAY_PROPERTY_PERSISTENT,
        DEVPROP_TYPE_BINARY,
        sizeof(capabilities), capabilities));
#pragma endregion

    return STATUS_SUCCESS;
}

Artigos relacionados

• Extensões de classe de áudio ACX
• Especificação do Perfil de Áudio Básico do Bluetooth
• Especificação do Bluetooth Core 5.3
• Especificação do Serviço de Recursos de Áudio Publicados por Bluetooth
• Especificação do Serviço de Controle de Fluxo de Áudio Bluetooth
• Números Atribuídos por Bluetooth
• Diretrizes de desvio para Bluetooth HFP em drivers de áudio
• Transmissão de áudio com desvio HFP do Bluetooth