Automatisation des tests d'interface audio sur les plates-formes embarquées

L'interface audio est devenue omniprésente de nos jours. Il est disponible sur la plupart des ordinateurs à carte unique (SBC) pour l'Internet industriel des objets (IIOT). Il existe plusieurs types d'interfaces disponibles, allant de l'audio analogique aux ports audio numériques. Chaque type de cette interface a ses propres défis en termes de conception et de test. Les tests de ces interfaces lors de l'assemblage et de la production impliquent le chemin complet entre le frontal analogique ou numérique et les ports d'entrée audio numérique d'une unité de traitement.

Le frontal audio sur une plate-forme intégrée et le flux générique de chemin de données audio dans un environnement de configuration de test de production sont illustrés ci-dessous (Figure 1),

Figure 1 : configuration de test et interface audio pour une plate-forme intégrée (source :auteur)

Le diagramme ci-dessus montre les principaux blocs/composants présents dans le chemin de données. Le CI récepteur présent peut être un CI frontal analogique tel qu'un convertisseur analogique-numérique (ADC) ou peut également être un CI récepteur audio numérique. La sortie de l'IC peut être dans n'importe quel format série comme Inter-IC Sound Bus (I2S). Cette interface peut transporter des données audio brutes au format de modulation par impulsions et codage (PCM).

L'objectif des tests de production est de s'assurer que le chemin audio complet est testé fonctionnellement pour toutes sortes de problèmes. Les problèmes possibles peuvent inclure les suivants :

• Défaillance du circuit intégré du récepteur frontal.

• Problèmes liés à l'assemblage sur les lignes I2S comme le blocage au niveau haut (connecté à l'alimentation) ou au niveau bas (connecté à la terre) ou un court-circuit entre plusieurs lignes de signal.

Ce test d'interface audio fera partie d'un système de test de production plus important qui testera toutes les interfaces sur une carte embarquée.

Vous trouverez ci-dessous une technique couramment utilisée pour détecter les problèmes liés à l'assemblage dans les tests d'interface audio. En cas de défaillance du circuit intégré du récepteur frontal, une technique différente doit être utilisée, mais ces techniques dépassent le cadre de ce document.

Technique 1 – Tests subjectifs

Les tests subjectifs consistent à capturer des échantillons de données audio pendant quelques secondes et à les comparer avec l'audio réel joué par l'inspection auditive. L'inconvénient de cette technique est qu'elle nécessite une intervention humaine et prend du temps. Par exemple, s'il y a plusieurs canaux stéréo, l'utilisateur doit écouter et confirmer l'un après l'autre.

Compte tenu des inconvénients de la technique ci-dessus, nous avons proposé un moyen innovant de tester les signaux de l'interface audio et d'automatiser l'ensemble du processus.

Technique 2 – Tests automatisés

Pour comprendre cette technique de test automatisé, il est important de comprendre certains concepts fondamentaux de l'interface I2S.

I2S a trois signaux – BCLK (horloge binaire), WCLK (horloge de mots), DATA (signaux de données). Si BCLK ou WCLK ne sont pas corrects (bloqués sur haut/bas), le port d'entrée audio du processeur ne réussira pas à capturer et donnera un résultat correspondant indiquant une défaillance de l'horloge. Si ces signaux sont corrects, la capture audio se produira quelle que soit la valeur de DATA. Maintenant, si DATA est bloqué à 1 ou 0, alors le tampon de données audio contiendra tous les FFFF ou tous les 0000 pour chaque échantillon de 16 bits. Ainsi, lorsque nous générons la somme de contrôle MD5, nous obtiendrons deux valeurs correspondantes :MD5(FFFF) et MD5(0000). Pour chaque autre valeur de données audio, la somme de contrôle MD5 sera différente. Ce concept peut être utilisé pour automatiser et vérifier les signaux de capture audio.

La procédure pour cette méthode consiste à capturer l'audio lorsque l'audio approprié est lu et n'est pas en mode muet. Cela garantira que notre fichier audio est uniquement capturé et que les données dans la mémoire tampon sont correctes. Une fois qu'un tampon de données audio a capturé environ 100 échantillons, sa somme de contrôle MD5 peut être générée. Si le signal DATA était bloqué au niveau haut, sa valeur de somme de contrôle MD5 sera la même que MD5 (FFFF) et s'il était bloqué au niveau bas, sa valeur de somme de contrôle MD5 sera la même que MD5 (0000). Si le signal DATA bascule, la valeur de la somme de contrôle MD5 sera toute autre valeur aléatoire. Par conséquent, sur la base de la valeur de la somme de contrôle MD5, nous pouvons conclure si le signal DATA a des problèmes.

Habituellement, ces lignes I2S auront plusieurs signaux de données. Nous pouvons le démontrer avec l'exemple suivant de bus I2S avec quatre signaux de données DATAx (x =0,1,2,3). Cela peut être fait en donnant des données audio sur l'un des signaux DATA et 0 pour tous les signaux de données restants. De cette façon, nous pouvons générer la somme de contrôle MD5 des données capturées de tous les DATAx (x =0,1,2,3) et confirmer que les valeurs de la somme de contrôle MD5 sont comme prévu.

Si nous avons donné des données audio sur DATA0 uniquement, la somme de contrôle MD5 pour les signaux DATA1-3 doit être MD5(0000) et pour DATA0, elle doit être une valeur aléatoire. Cela peut être fait pour les quatre signaux de données l'un après l'autre en quatre itérations, comme indiqué dans le tableau 1.

cliquez pour agrandir l'image

Tableau 1 :Itération des tests audio (Source :auteur)

La limitation de cette technique est qu'elle ne peut être utilisée que pour identifier les problèmes décrits ci-dessus. Pour certains cas d'utilisation, il ne peut pas faire la distinction entre les problèmes. Par exemple, si plusieurs lignes de signal sont court-circuitées, la technique peut détecter qu'un problème est présent mais elle ne peut pas dire clairement quelles lignes sont court-circuitées ensemble.

Conclusion

Les méthodes mentionnées ci-dessus ont été testées et sont actuellement utilisées avec succès pour tester les interfaces d'entrée audio sur de nombreuses cartes matérielles développées par Ittiam. Nous avons vu que cela a réduit le temps de test global des interfaces audio, ce qui a entraîné une baisse des coûts de test de la carte.

---

Ayusman Mohanty est un architecte produit spécialisé dans la construction de matériel pour les systèmes de diffusion et de surveillance vidéo et audio. Il est joignable via Linkedin.