Automatizando o teste de interface de áudio em plataformas incorporadas

A interface de áudio se tornou onipresente hoje em dia. Ele está disponível na maioria dos computadores de placa única (SBCs) para a Internet das coisas industrial (IIOT). Existem vários tipos de interfaces disponíveis, desde áudio analógico até portas de áudio digital. Cada tipo dessa interface tem seus próprios desafios de design e teste. O teste dessas interfaces durante a montagem e produção envolve o caminho completo do front-end analógico ou digital às portas de entrada de áudio digital de uma unidade de processamento.

O front-end de áudio em uma plataforma incorporada e o fluxo genérico do caminho de dados de áudio em um ambiente de configuração de teste de produção são mostrados abaixo (Figura 1),

Figura 1:Configuração de teste e front-end de áudio para uma plataforma incorporada (fonte:autor)

O diagrama acima mostra os principais blocos / componentes presentes no caminho de dados. O IC receptor presente pode ser um IC analógico frontal, como um conversor analógico-digital (ADC) ou também pode ser um IC receptor de áudio digital. A saída do IC pode estar em qualquer formato serial, como Inter-IC Sound Bus (I2S). Essa interface pode transportar dados de áudio brutos no formato de modulação por código de pulso (PCM).

O objetivo do teste de produção é garantir que o caminho de áudio completo seja testado funcionalmente para todos os tipos de problemas. Os possíveis problemas podem incluir o seguinte:

• Falha de IC do receptor de front end.
  

• Problemas relacionados à montagem em linhas I2S como presa na alta (conectada à fonte) ou presa na baixa (conectada ao aterramento) ou curto-circuito entre múltiplas linhas de sinal.
  

Este teste de interface de áudio fará parte de um sistema de teste de produção maior que testará todas as interfaces em uma placa embarcada.

Listada abaixo está uma técnica comum usada para detectar problemas relacionados à montagem em testes de interface de áudio. Para falha do IC do receptor front-end, uma técnica diferente precisa ser usada, mas essas técnicas estão além do escopo deste documento.

Técnica 1 - Teste Subjetivo

O teste subjetivo envolve a captura de amostras de dados de áudio por alguns segundos e a comparação com o áudio real sendo reproduzido pela inspeção auditiva. A desvantagem dessa técnica é que ela precisa da intervenção humana e é demorada. Por exemplo, se houver vários canais estéreo, o usuário precisará ouvir e confirmar um após o outro.

Considerando as desvantagens da técnica acima, criamos uma maneira inovadora de testar os sinais da interface de áudio e automatizar todo o processo.

Técnica 2 - teste automatizado

Para entender essa técnica de teste automatizado, é importante entender alguns conceitos fundamentais da interface I2S.

O I2S possui três sinais - BCLK (bit clock), WCLK (word clock), DATA (sinais de dados). Se o BCLK ou WCLK não estiverem adequados (presos em alto / baixo), a porta de entrada de áudio do processador não será capturada e dará um resultado correspondente mostrando falha de clock. Se esses sinais estiverem bons, a captura de áudio acontecerá independentemente do valor de DATA. Agora, se DATA estiver travado em 1 ou 0, o buffer de dados de áudio conterá todos os FFFF ou todos os 0000 para cada amostra de 16 bits. Assim, quando geramos a soma de verificação MD5, obteremos dois valores correspondentes:MD5 (FFFF) e MD5 (0000). Para cada outro valor de dados de áudio, a soma de verificação MD5 será diferente. Este conceito pode ser usado para automatizar e verificar os sinais de captura de áudio.

O procedimento para este método é capturar o áudio quando o áudio adequado está sendo reproduzido e não está no estado mudo. Isso garantirá que nosso arquivo de áudio seja apenas capturado e que os dados no buffer estejam corretos. Uma vez que um buffer de dados de áudio tenha capturado cerca de 100 amostras, então sua soma de verificação MD5 pode ser gerada. Se o sinal DATA ficou preso em alto, então seu valor de checksum MD5 será igual ao MD5 (FFFF) e se ficou preso em baixo, então seu valor de checksum MD5 será o mesmo que MD5 (0000). Se o sinal DATA estiver alternando, o valor da soma de verificação MD5 será qualquer outro valor aleatório. Portanto, com base no valor de checksum MD5, podemos chegar a uma conclusão sobre se o sinal DATA tem algum problema.

Normalmente, essas linhas I2S terão vários sinais de dados. Podemos demonstrar isso com o seguinte exemplo de barramento I2S com quatro sinais de dados DATAx (x =0,1,2,3). Isso pode ser feito fornecendo dados de áudio em um dos sinais DATA e 0 para todos os sinais de dados restantes. Desta forma, podemos gerar a soma de verificação MD5 dos dados capturados de todos os DATAx (x =0,1,2,3) e confirmar se os valores da soma de verificação MD5 são os esperados.

Se tivermos fornecido dados de áudio apenas em DATA0, a soma de verificação MD5 para sinais DATA1-3 deve ser MD5 (0000) e para DATA0 deve ser algum valor aleatório. Isso pode ser feito para todos os quatro sinais de dados, um após o outro, em quatro iterações, conforme mostrado na Tabela 1.

clique para ampliar a imagem

Tabela 1:Iteração de Teste de Áudio (Fonte:Autor)

A limitação dessa técnica é que ela pode ser usada apenas para identificar os problemas descritos acima. Para alguns casos de uso, ele não consegue distinguir entre os problemas. Por exemplo, se várias linhas de sinal estiverem em curto, a técnica pode detectar que um problema está presente, mas não pode dizer claramente quais linhas estão em curto.

Conclusão

Os métodos mencionados acima foram testados e estão sendo usados ​​com sucesso para testar interfaces de entrada de áudio em muitas placas de hardware desenvolvidas pela Ittiam. Vimos que isso reduziu o tempo geral de teste das interfaces de áudio, resultando em menor custo de teste da placa.

---

Ayusman Mohanty é arquiteto de produto com foco principal na construção de hardware para transmissão de vídeo e áudio e sistemas de vigilância. Ele pode ser contatado pelo Linkedin.