Este artigo analisa o suporte do Android para áudio digital USB e protocolos baseados em USB relacionados.
Público
O público-alvo deste artigo são OEMs de dispositivos Android, fornecedores de SoC, fornecedores de periféricos de áudio USB, desenvolvedores avançados de aplicativos de áudio e outros que buscam compreensão detalhada dos componentes internos de áudio digital USB no Android.
Os usuários finais de dispositivos Nexus devem consultar o artigo Gravar e reproduzir áudio usando o modo de host USB na Central de Ajuda do Nexus . Embora este artigo não seja voltado para usuários finais, alguns consumidores audiófilos podem encontrar partes de seu interesse.
Visão geral do USB
O Universal Serial Bus (USB) é descrito informalmente no artigo da Wikipedia USB , e é formalmente definido pelos padrões publicados pelo USB Implementers Forum, Inc . Por conveniência, resumimos os principais conceitos USB aqui, mas os padrões são a referência oficial.
Conceitos básicos e terminologia
USB é um barramento com um único iniciador de operações de transferência de dados, chamado de host . O host se comunica com os periféricos através do barramento.
Nota: Os termos dispositivo e acessório são sinônimos comuns para periféricos . Evitamos esses termos aqui, pois eles podem ser confundidos com o dispositivo Android ou o conceito específico do Android chamado modo acessório .
Uma função crítica do host é a enumeração : o processo de detectar quais periféricos estão conectados ao barramento e consultar suas propriedades expressas por meio de descritores .
Um periférico pode ser um objeto físico, mas na verdade implementa múltiplas funções lógicas. Por exemplo, um periférico de webcam pode ter uma função de câmera e uma função de áudio de microfone.
Cada função periférica possui uma interface que define o protocolo para comunicação com aquela função.
O host se comunica com um periférico por meio de um pipe para um endpoint , uma fonte de dados ou um coletor fornecido por uma das funções do periférico.
Existem dois tipos de pipes: message e stream . Um pipe de mensagem é usado para controle e status bidirecional. Um canal de fluxo é usado para transferência de dados unidirecional.
O host inicia todas as transferências de dados, portanto, os termos entrada e saída são expressos em relação ao host. Uma operação de entrada transfere dados do periférico para o host, enquanto uma operação de saída transfere dados do host para o periférico.
Existem três modos principais de transferência de dados: interrupção , massa e isócrona . O modo isócrono será discutido mais adiante no contexto de áudio.
O periférico pode ter terminais que se conectam ao mundo exterior, além do próprio periférico. Desta forma, o periférico serve para traduzir entre o protocolo USB e os sinais do "mundo real". Os terminais são objetos lógicos da função.
Modos USB Android
Modo de desenvolvimento
O modo de desenvolvimento está presente desde o lançamento inicial do Android. O dispositivo Android aparece como um periférico USB para um PC host executando um sistema operacional de desktop, como Linux, Mac OS X ou Windows. A única função periférica visível é o Android fastboot ou o Android Debug Bridge (adb) . Os protocolos fastboot e adb são colocados em camadas no modo de transferência de dados em massa USB.
Modo de host
O modo de host é introduzido no Android 3.1 (API de nível 12).
Como o dispositivo Android deve atuar como host, e a maioria dos dispositivos Android inclui um conector micro-USB que não permite diretamente a operação do host, geralmente é necessário um adaptador on-the-go ( OTG ) como este:
![OTG](https://source.android.com/static/devices/audio/images/otg.jpg?authuser=6&hl=pt)
Figura 1. Adaptador móvel (OTG)
Um dispositivo Android pode não fornecer energia suficiente para operar um periférico específico, dependendo de quanta energia o periférico precisa e de quanta o dispositivo Android é capaz de fornecer. Mesmo que a energia adequada esteja disponível, a carga da bateria do dispositivo Android pode ser significativamente reduzida. Para essas situações, use um hub energizado como este:
![Hub energizado](https://source.android.com/static/devices/audio/images/hub.jpg?authuser=6&hl=pt)
Figura 2. Hub energizado
Modo acessório
O modo acessório foi introduzido no Android 3.1 (API de nível 12) e portado de volta para o Android 2.3.4. Nesse modo, o dispositivo Android funciona como um periférico USB, sob o controle de outro dispositivo, como um dock que serve como host. A diferença entre o modo de desenvolvimento e o modo acessório é que as funções USB adicionais são visíveis para o host, além do adb. O dispositivo Android começa no modo de desenvolvimento e depois passa para o modo acessório por meio de um processo de renegociação.
O modo acessório foi estendido com recursos adicionais no Android 4.1, em particular o áudio descrito abaixo.
Áudio USB
aulas USB
Cada função periférica tem um documento de classe de dispositivo associado que especifica o protocolo padrão para essa função. Isso permite que hosts compatíveis com a classe e funções periféricas interoperem, sem conhecimento detalhado do funcionamento de cada um. A conformidade de classe é crítica se o host e o periférico forem fornecidos por entidades diferentes.
O termo driverless é um sinônimo comum para class compliant , indicando que é possível usar os recursos padrão de tal periférico sem exigir a instalação de um driver específico do sistema operacional. Pode-se supor que um periférico anunciado como "sem driver necessário" para os principais sistemas operacionais de desktop será compatível com a classe, embora possa haver exceções.
aula de áudio USB
Aqui nos preocupamos apenas com periféricos que implementam funções de áudio e, portanto, aderem à classe de dispositivos de áudio. Existem duas edições da especificação de classe de áudio USB: classe 1 (UAC1) e 2 (UAC2).
Comparação com outras classes
O USB inclui muitas outras classes de dispositivos, algumas das quais podem ser confundidas com a classe de áudio. A classe de armazenamento em massa (MSC) é usada para acesso orientado por setor à mídia, enquanto o Media Transfer Protocol (MTP) é para acesso completo de arquivo à mídia. Tanto o MSC quanto o MTP podem ser usados para transferir arquivos de áudio, mas apenas a classe de áudio USB é adequada para streaming em tempo real.
Terminais de áudio
Os terminais de um periférico de áudio são tipicamente analógicos. O sinal analógico apresentado no terminal de entrada do periférico é convertido para digital por um conversor analógico-digital (ADC), e é transportado pelo protocolo USB para ser consumido pelo host. O ADC é uma fonte de dados para o host. Da mesma forma, o host envia um sinal de áudio digital através do protocolo USB para o periférico, onde um conversor digital-analógico (DAC) converte e apresenta a um terminal de saída analógica. O DAC é um coletor para o host.
Canais
Um periférico com função de áudio pode incluir um terminal de origem, um terminal de dreno ou ambos. Cada direção pode ter um canal ( mono ), dois canais ( estéreo ) ou mais. Periféricos com mais de dois canais são chamados de multicanais . É comum interpretar um fluxo estéreo como consistindo de canais esquerdo e direito e, por extensão, interpretar um fluxo multicanal como tendo localizações espaciais correspondentes a cada canal. No entanto, também é bastante apropriado (especialmente para áudio USB mais do que HDMI ) não atribuir nenhum significado espacial padrão específico a cada canal. Nesse caso, cabe ao aplicativo e ao usuário definir como cada canal é utilizado. Por exemplo, um fluxo de entrada USB de quatro canais pode ter os três primeiros canais conectados a vários microfones em uma sala e o canal final recebendo entrada de um rádio AM.
Modo de transferência isócrona
O áudio USB usa o modo de transferência isócrona para suas características em tempo real, em detrimento da recuperação de erros. No modo isócrono, a largura de banda é garantida e os erros de transmissão de dados são detectados usando uma verificação de redundância cíclica (CRC). Mas não há confirmação de pacote ou retransmissão em caso de erro.
As transmissões isócronas ocorrem a cada período de início de quadro (SOF). O período SOF é de um milissegundo para velocidade total e 125 microssegundos para alta velocidade. Cada quadro de velocidade máxima carrega até 1.023 bytes de carga útil e um quadro de alta velocidade carrega até 1.024 bytes. Juntando tudo isso, calculamos a taxa de transferência máxima como 1.023.000 ou 8.192.000 bytes por segundo. Isso define um limite superior teórico na taxa de amostragem de áudio combinada, contagem de canais e profundidade de bits. O limite prático é menor.
Dentro do modo isócrono, existem três submodos:
- Adaptativo
- Assíncrono
- Síncrono
No submodo adaptativo, o coletor ou fonte periférico se adapta a uma taxa de amostragem potencialmente variável do host.
No submodo assíncrono (também chamado de feedback implícito), o coletor ou fonte determina a taxa de amostragem e o host acomoda. A principal vantagem teórica do submodo assíncrono é que o clock USB de origem ou coletor está fisicamente e eletricamente mais próximo (e de fato pode ser o mesmo ou derivado) do clock que aciona o DAC ou ADC. Essa proximidade significa que o submodo assíncrono deve ser menos suscetível ao jitter do clock. Além disso, o relógio usado pelo DAC ou ADC pode ser projetado para maior precisão e menor desvio do que o relógio do host.
No submodo síncrono, um número fixo de bytes é transferido a cada período SOF. A taxa de amostragem de áudio é efetivamente derivada do relógio USB. O submodo síncrono não é comumente usado com áudio porque tanto o host quanto o periférico estão à mercê do relógio USB.
A tabela abaixo resume os submodos isócronos:
Sub-modo | Contagem de bytes por pacote | Taxa de amostragem determinado por | Usado para áudio |
---|---|---|---|
adaptável | variável | hospedeiro | sim |
assíncrono | variável | periférico | sim |
síncrono | fixo | relógio USB | não |
Na prática, o submodo é importante, mas outros fatores também devem ser considerados.
Suporte Android para classe de áudio USB
Modo de desenvolvimento
O áudio USB não é suportado no modo de desenvolvimento.
Modo de host
O Android 5.0 (API de nível 21) e superior é compatível com um subconjunto de recursos de áudio USB classe 1 (UAC1):
- O dispositivo Android deve atuar como host
- O formato de áudio deve ser PCM (interface tipo I)
- A profundidade de bits deve ser de 16 bits, 24 bits ou 32 bits, onde 24 bits de dados de áudio úteis são justificados à esquerda dentro dos bits mais significativos da palavra de 32 bits
- A taxa de amostragem deve ser 48, 44,1, 32, 24, 22,05, 16, 12, 11,025 ou 8 kHz
- A contagem de canais deve ser 1 (mono) ou 2 (estéreo)
A leitura do código-fonte da estrutura do Android pode mostrar código adicional além do mínimo necessário para oferecer suporte a esses recursos. Mas esse código não foi validado, portanto, recursos mais avançados ainda não foram reivindicados.
Modo acessório
O Android 4.1 (API de nível 16) adicionou suporte limitado para reprodução de áudio no host. No modo acessório, o Android roteia automaticamente sua saída de áudio para USB. Ou seja, o dispositivo Android serve como fonte de dados para o host, por exemplo, um dock.
O áudio do modo acessório tem estes recursos:
- O dispositivo Android deve ser controlado por um host experiente que pode primeiro fazer a transição do dispositivo Android do modo de desenvolvimento para o modo acessório e, em seguida, o host deve transferir dados de áudio do endpoint apropriado. Assim, o dispositivo Android não aparece "sem driver" para o host.
- A direção deve ser de entrada , expressa em relação ao host
- O formato de áudio deve ser PCM de 16 bits
- A taxa de amostragem deve ser de 44,1 kHz
- A contagem de canais deve ser 2 (estéreo)
O áudio do modo acessório não foi amplamente adotado e atualmente não é recomendado para novos designs.
Aplicações de áudio digital USB
Como o nome indica, o sinal de áudio digital USB é representado por um fluxo de dados digital em vez do sinal analógico usado pelo conector de mini fone de ouvido TRS comum. Eventualmente, qualquer sinal digital deve ser convertido em analógico antes que possa ser ouvido. Existem compensações na escolha de onde colocar essa conversão.
Um conto de dois DACs
No diagrama de exemplo abaixo, comparamos dois designs. Primeiro, temos um dispositivo móvel com Processador de Aplicativo (AP), DAC integrado, amplificador e conector TRS analógico conectado aos fones de ouvido. Também consideramos um dispositivo móvel com USB conectado a USB externo DAC e amplificador, também com fones de ouvido.
![Comparação de DAC](https://source.android.com/static/devices/audio/images/dac.png?authuser=6&hl=pt)
Figura 3. Comparação de dois DACs
Qual desenho é melhor? A resposta depende de suas necessidades. Cada um tem vantagens e desvantagens.
Nota: Esta é uma comparação artificial, pois um dispositivo Android real provavelmente teria as duas opções disponíveis.
O primeiro projeto A é mais simples, menos caro, usa menos energia e será um projeto mais confiável assumindo componentes igualmente confiáveis. No entanto, geralmente há compensações de qualidade de áudio em relação a outros requisitos. Por exemplo, se este for um dispositivo de mercado de massa, ele pode ser projetado para atender às necessidades do consumidor em geral, não para o audiófilo.
No segundo design, o periférico de áudio externo C pode ser projetado para maior qualidade de áudio e maior potência sem afetar o custo do dispositivo Android básico de mercado de massa B. Sim, é um design mais caro, mas o custo é absorvido apenas por aqueles que o querem.
Os dispositivos móveis são famosos por terem placas de circuito de alta densidade, o que pode resultar em mais oportunidades de crosstalk que degradam os sinais analógicos adjacentes. A comunicação digital é menos suscetível a ruído , portanto, mover o DAC do dispositivo Android A para uma placa de circuito externa C permite que os estágios analógicos finais sejam isolados física e eletricamente da placa de circuito densa e barulhenta, resultando em áudio de maior fidelidade.
Por outro lado, o segundo design é mais complexo e, com complexidade adicional, surgem mais oportunidades para que as coisas falhem. Há também latência adicional dos controladores USB.
Aplicativos de modo host
Os aplicativos típicos de áudio do modo host USB incluem:
- ouvir música
- telefonia
- mensagens instantâneas e bate-papo por voz
- gravação
Para todos esses aplicativos, o Android detecta um periférico de áudio digital USB compatível e roteia automaticamente a reprodução e a captura de áudio de forma adequada, com base nas regras da política de áudio. O conteúdo estéreo é reproduzido nos dois primeiros canais do periférico.
Não há APIs específicas para áudio digital USB. Para uso avançado, o roteamento automático pode interferir em aplicativos compatíveis com USB. Para esses aplicativos, desative o roteamento automático por meio do controle correspondente na seção Mídia de Configurações/Opções do desenvolvedor .
Depuração no modo host
Enquanto estiver no modo de host USB, a depuração adb por USB não está disponível. Consulte a seção Uso sem fio do Android Debug Bridge para obter uma alternativa.
Implementação de áudio USB
Recomendações para fornecedores de periféricos de áudio
Para interoperar com dispositivos Android, os fornecedores de periféricos de áudio devem:
- projeto para conformidade de classe de áudio; atualmente o Android tem como alvo a classe 1, mas é aconselhável planejar para a classe 2
- evitar peculiaridades
- teste de interoperabilidade com dispositivos Android populares e de referência
- documente claramente os recursos suportados, a conformidade da classe de áudio, os requisitos de energia, etc., para que os consumidores possam tomar decisões informadas
Recomendações para OEMs de dispositivos Android e fornecedores de SoC
Para oferecer suporte ao áudio digital USB, os OEMs de dispositivos e fornecedores de SoC devem:
- hardware de design para suportar o modo host USB
- habilitar o suporte genérico de host USB no nível da estrutura por meio do sinalizador de recurso
android.hardware.usb.host.xml
- habilitar todos os recursos do kernel necessários: modo host USB, áudio USB, modo de transferência isócrona; consulte Configuração do kernel do Android
- manter-se atualizado com os lançamentos e patches recentes do kernel; apesar do nobre objetivo de conformidade de classe, existem periféricos de áudio com peculiaridades , e kernels recentes têm soluções alternativas para tais peculiaridades
- ativar a política de áudio USB conforme descrito abaixo
- adicione audio.usb.default a PRODUCT_PACKAGES em device.mk
- teste de interoperabilidade com periféricos de áudio USB comuns
Como habilitar a política de áudio USB
Para habilitar o áudio USB, adicione uma entrada ao arquivo de configuração de política de áudio. Isso geralmente está localizado aqui:
device/oem/codename/audio_policy.conf
O componente do nome do caminho "oem" deve ser substituído pelo nome do OEM que fabrica o dispositivo Android e "codename" deve ser substituído pelo nome do código do dispositivo.
Uma entrada de exemplo é mostrada aqui:
audio_hw_modules { ... usb { outputs { usb_accessory { sampling_rates 44100 channel_masks AUDIO_CHANNEL_OUT_STEREO formats AUDIO_FORMAT_PCM_16_BIT devices AUDIO_DEVICE_OUT_USB_ACCESSORY } usb_device { sampling_rates dynamic channel_masks dynamic formats dynamic devices AUDIO_DEVICE_OUT_USB_DEVICE } } inputs { usb_device { sampling_rates dynamic channel_masks AUDIO_CHANNEL_IN_STEREO formats AUDIO_FORMAT_PCM_16_BIT devices AUDIO_DEVICE_IN_USB_DEVICE } } } ... }
Código fonte
A implementação de HAL (Hardware Abstraction Layer) de áudio para áudio USB está localizada aqui:
hardware/libhardware/modules/usbaudio/
O HAL de áudio USB depende muito do tinyalsa , descrito em Audio Terminology . Embora o áudio USB dependa de transferências isócronas, isso é abstraído pela implementação do ALSA. Portanto, o áudio USB HAL e o tinyalsa não precisam se preocupar com essa parte do protocolo USB.
Testando áudio USB
Para obter informações sobre o teste de CTS para áudio USB, consulte Testes do verificador de CTS de áudio USB.