Un traitement acoustique en temps réel réussi nécessite une planification minutieuse

Le traitement acoustique en temps réel à faible latence est un facteur clé dans de nombreuses applications de traitement embarqué, parmi lesquelles le prétraitement vocal, la reconnaissance vocale et la suppression active du bruit (ANC). Alors que les exigences de performances en temps réel augmentent régulièrement dans ces domaines d'application, les développeurs doivent adopter un état d'esprit stratégique pour répondre correctement à ces besoins. Compte tenu des performances substantielles offertes par de nombreux systèmes plus grands sur puces, il peut être tentant de simplement charger ces appareils avec toutes les tâches supplémentaires qui surviennent, mais il est important de comprendre que la latence et le déterminisme sont des éléments critiques qui peuvent facilement conduire à un système en temps réel majeur. problèmes s'il n'est pas examiné attentivement. Cet article explore les problèmes que les concepteurs doivent prendre en compte lorsqu'ils choisissent entre un SoC et un DSP audio dédié afin d'éviter les mauvaises surprises dans leurs systèmes acoustiques en temps réel.

Les systèmes acoustiques à faible latence couvrent un large éventail d'applications. Par exemple, dans le seul domaine automobile, une faible latence est essentielle pour les zones audio personnelles, la suppression du bruit de la route et les systèmes de communication embarqués, pour n'en nommer que quelques-uns.

Avec la tendance émergente de l'électrification des véhicules, l'ANC devient encore plus important car il n'y a pas de moteur à combustion générant un bruit perceptible. Par conséquent, les sons associés à l'interface voiture-route deviennent beaucoup plus perceptibles et offensants. La réduction de ce bruit crée non seulement une expérience de conduite plus confortable, mais réduit également la fatigue du conducteur. Il existe de nombreux défis associés à la mise en œuvre d'un système acoustique à faible latence sur un SoC par opposition à un DSP audio dédié. Ceux-ci incluent des problèmes de latence, d'évolutivité, d'évolutivité, de considérations d'algorithme, d'accélération matérielle et de support client. Examinons chacun d'eux à tour de rôle.

Latence

La question de la latence dans les systèmes de traitement acoustique en temps réel est importante. Si le processeur ne peut pas suivre le mouvement des données en temps réel et les demandes de calcul du système, des chutes audio inacceptables peuvent en résulter.

En règle générale, les SoC ont de petites SRAM sur puce et, par conséquent, doivent s'appuyer sur le cache pour la plupart des accès à la mémoire locale. Cela introduit une disponibilité non déterministe du code et des données, et augmente également la latence de traitement. Pour une application en temps réel telle que l'ANC, cela seul peut être un facteur décisif. Cependant, il y a aussi le fait que les SoC exécutent des systèmes d'exploitation non temps réel qui gèrent de lourdes charges multitâches. Cela amplifie la caractéristique de fonctionnement non déterministe du système, ce qui rend très difficile la prise en charge d'un traitement acoustique relativement complexe dans un environnement multitâche.

La figure 1 montre un exemple concret d'un SoC exécutant une charge de traitement audio en temps réel, où la charge du processeur augmente lorsque les tâches SoC de priorité plus élevée sont gérées. Ces pics peuvent se produire, par exemple, en raison d'activités centrées sur le SoC telles que le rendu multimédia, la navigation ou l'exécution d'applications sur le système. Chaque fois que les pics dépassent 100 % de charge du processeur, le SoC ne fonctionne plus en temps réel, ce qui entraîne des pertes audio.

cliquez pour l'image en taille réelle

Figure 1 :Charges CPU instantanées pour un SoC représentatif exécutant un traitement de mémoire audio élevé en plus d'autres tâches [1]. (Source :Appareils analogiques)

Les DSP audio, quant à eux, sont conçus pour une faible latence tout au long du chemin de traitement du signal, de l'entrée audio échantillonnée à la sortie du haut-parleur composite (par exemple, audio + anti-bruit). L'instruction L1 et la SRAM de données, la mémoire à cycle unique la plus proche du cœur du processeur, est suffisamment ample pour prendre en charge de nombreux algorithmes de traitement sans décharger les données intermédiaires vers la mémoire hors puce. De plus, la mémoire L2 sur puce (plus éloignée du cœur mais toujours beaucoup plus rapide que la DRAM hors puce) permet de fournir une mémoire tampon pour les opérations de données intermédiaires lorsque le stockage L1 SRAM est dépassé. Enfin, les DSP audio exécutent généralement un système d'exploitation en temps réel (RTOS) qui garantit que les données entrantes peuvent être traitées et envoyées à leur destination cible avant l'arrivée de nouvelles données d'entrée, garantissant ainsi que les tampons de données ne débordent pas pendant le fonctionnement en temps réel.

La latence réelle au démarrage du système, souvent mesurée par le temps de disponibilité audio, peut également être une mesure importante, en particulier dans les systèmes automobiles où des avertissements sonores doivent être diffusés dans une certaine fenêtre à partir du démarrage. Dans le monde des SoC, où il est courant d'avoir une longue séquence de démarrage qui implique l'installation du système d'exploitation pour l'ensemble de l'appareil, il peut être difficile, voire impossible, de répondre à cette exigence de démarrage. D'un autre côté, un DSP audio autonome exécutant son propre RTOS non affecté par d'autres priorités système étrangères peut être optimisé pour un démarrage rapide qui satisfait confortablement l'exigence de temps avant audio.

Évolutivité

Alors que les problèmes de latence sont problématiques pour les SoC dans des applications telles que le contrôle du bruit, un autre inconvénient majeur pour les SoC aspirant à effectuer un traitement acoustique est l'évolutivité. En d'autres termes, les SoC qui contrôlent de grands systèmes (tels que les unités de tête de réseau et les clusters automobiles) avec de nombreux sous-systèmes disparates ne peuvent pas facilement passer des besoins audio bas de gamme aux besoins audio haut de gamme car il existe un conflit constant entre les besoins d'évolutivité de chaque composant de sous-système, nécessitant compromis dans l'utilisation globale du SoC. Par exemple, si un SoC de tête de réseau se connecte à un tuner distant et, sur tous les modèles automobiles, ce tuner doit passer de quelques canaux à plusieurs canaux, chaque configuration de canal amplifiera les problèmes de temps réel mentionnés précédemment. Cela est dû au fait que chaque fonctionnalité supplémentaire sous le contrôle du SoC modifie le comportement en temps réel du SoC et la disponibilité des ressources des composants architecturaux clés utilisés par plusieurs fonctions. Ces ressources incluent des aspects tels que la bande passante mémoire, les cycles de cœur de processeur et les slots d'arbitrage de matrice de bus système.

Outre la préoccupation concernant la connexion d'autres sous-systèmes au SoC multitâche, le sous-système acoustique lui-même a ses propres problèmes d'évolutivité. Il existe une mise à l'échelle du bas vers le haut (par exemple, l'augmentation du nombre de canaux de microphone et de haut-parleur dans une application ANC), et il y a aussi la mise à l'échelle de l'expérience audio, du décodage audio de base et de la lecture stéréo jusqu'à la virtualisation 3D et d'autres fonctionnalités premium. Bien que ces exigences ne partagent pas les contraintes temps réel des systèmes ANC, elles sont néanmoins directement liées au choix du processeur audio pour un système.

L'utilisation d'un DSP audio séparé en tant que coprocesseur d'un SoC permet de résoudre le problème d'évolutivité audio, permet une conception de système modulaire et optimise les coûts (voir Figure 2). Le SoC peut se concentrer beaucoup moins sur les besoins de traitement acoustique en temps réel du système plus vaste, au lieu de décharger ce traitement sur le DSP audio à faible latence. De plus, les DSP audio qui offrent plusieurs niveaux de prix/performances/mémoire sur une feuille de route complète compatible avec les codes et les broches offrent une flexibilité maximale aux concepteurs de systèmes pour dimensionner correctement l'offre de performances audio pour un niveau de produit donné.

cliquez pour l'image en taille réelle

Figure 2 :illustrant un processeur audio hautement évolutif. L'utilisation d'un processeur audio séparé, tel que le DSP ADSP-2156x illustré ici, aide à résoudre le problème d'évolutivité audio, permet une conception de système modulaire et optimise les coûts. (Source :Analog Devices)

Amélioration

À mesure que les mises à jour du micrologiciel en direct deviennent plus courantes dans les véhicules d'aujourd'hui, la possibilité de mise à niveau pour émettre des correctifs critiques ou fournir de nouvelles fonctionnalités devient de plus en plus importante. Cela peut entraîner des problèmes majeurs pour un SoC en raison des dépendances accrues entre ses différents sous-systèmes. Premièrement, sur les SoC, plusieurs threads de traitement et de transfert de données se disputent les ressources. Cela augmente la concurrence pour les processeurs MIPS et la mémoire lorsque de nouvelles fonctionnalités sont ajoutées, en particulier pendant les pics d'activité. Du point de vue audio, les ajouts de fonctionnalités dans d'autres domaines de contrôle SoC peuvent avoir un effet imprévisible sur les performances acoustiques en temps réel. Un effet secondaire de cette situation est que les nouvelles fonctionnalités doivent être testées de manière croisée sur tous les plans de fonctionnement, ce qui entraîne une myriade de permutations entre les différents modes de fonctionnement des sous-systèmes concurrents. Ainsi, la vérification du logiciel augmente de façon exponentielle pour chaque package de mise à niveau.

Vu sous un angle différent, on pourrait dire que les améliorations des performances audio du SoC dépendent des MIPS SoC disponibles, en plus des feuilles de route des fonctionnalités pour les autres sous-systèmes contrôlés par le SoC.

Développement et performances d'algorithmes

Il devrait être évident que, lorsqu'il s'agit de développer des algorithmes acoustiques en temps réel, les DSP audio sont spécialement conçus pour cette tâche. En tant que différentiateur important des SoC, les DSP audio autonomes peuvent offrir des environnements de développement graphique qui permettent aux ingénieurs ayant une expérience minimale du codage DSP d'ajouter un traitement acoustique de qualité à leurs conceptions. Ce type d'outil peut réduire les coûts de développement en réduisant le temps de développement sans sacrifier la qualité ou les performances.

À titre d'exemple, l'environnement de développement audio graphique SigmaStudio d'ADI offre une grande variété d'algorithmes de traitement du signal intégrés dans une interface utilisateur graphique (GUI) intuitive, permettant la création de flux de signaux audio complexes (voir Figure 3). Il prend également en charge la configuration graphique A2B pour le transport audio, ce qui contribue grandement à catalyser le développement de systèmes acoustiques en temps réel.

cliquez pour l'image en taille réelle

Figure 3 :Les environnements de développement audio graphiques comme SigmaStudio d'Analog Devices donnent accès à une grande variété d'algorithmes de traitement du signal intégrés dans une interface utilisateur graphique (GUI) intuitive, simplifiant la création de flux de signaux audio complexes. (Source :Appareils analogiques)

Fonctionnalités matérielles compatibles avec l'audio

En plus d'une architecture de cœur de processeur spécialement conçue pour des calculs à virgule flottante parallèles efficaces et des accès aux données, les DSP audio ont souvent des accélérateurs multicanaux dédiés pour les primitives audio courantes telles que les transformées de Fourier rapides (FFT), les réponses impulsionnelles finies et infinies (FIR et IIR ) filtrage et conversion de fréquence d'échantillonnage asynchrone (ASRC). Ceux-ci permettent le filtrage audio en temps réel, l'échantillonnage et la conversion du domaine fréquentiel en dehors du processeur central, augmentant ainsi les performances effectives du cœur. De plus, ils peuvent faciliter un modèle de programmation flexible et convivial grâce à leur architecture optimisée et leurs capacités de gestion des flux de données.

En raison de la prolifération du nombre de canaux audio, des flux de filtres, des taux d'échantillonnage, etc., il est important d'avoir une interface à broches configurable au maximum qui permet la conversion de taux d'échantillonnage en ligne, une horloge de précision et des ports série synchrones à grande vitesse pour acheminer efficacement les données et évitez la latence ajoutée ou la logique d'interface externe. L'interconnexion audio numérique (DAI) des processeurs de la famille SHARC d'ADI illustre cette capacité, comme le montre la figure 4.

cliquez pour l'image en taille réelle

Figure 4 :Une interconnexion audio numérique (DAI) est une interface à broches configurable au maximum qui permet une conversion de fréquence d'échantillonnage en ligne, une horloge de précision et des ports série synchrones à grande vitesse pour acheminer efficacement les données et éviter une latence supplémentaire ou logique d'interface externe. (Source :Appareils analogiques)

Assistance client

Un aspect souvent négligé du développement avec un processeur intégré est le support client pour l'appareil.

Bien que les fournisseurs de SoC encouragent l'exécution d'algorithmes acoustiques sur leurs produits DSP intégrés, cela comporte plusieurs responsabilités dans la pratique. D'une part, le support des fournisseurs est souvent plus complexe, car l'expertise acoustique n'est généralement pas le domaine du développement d'applications SoC. Par conséquent, les clients cherchant à développer leurs propres algorithmes acoustiques sur la technologie DSP sur puce du SoC tendent à être peu pris en charge. Au lieu de cela, le fournisseur peut proposer des algorithmes standard et facturer un NRE important pour porter les algorithmes acoustiques sur un ou plusieurs cœurs du SoC. Même ainsi, il n'y a aucune garantie de succès, surtout si le fournisseur ne propose pas de logiciel de framework mature et à faible latence. Enfin, l'écosystème tiers pour le traitement acoustique basé sur le SoC a tendance à être plutôt fragile, car il ne s'agit pas d'un objectif du SoC, mais plutôt d'une fonctionnalité prise en charge de manière opportuniste.

Un DSP audio spécialement conçu comporte un écosystème beaucoup plus solide pour le développement de systèmes acoustiques complexes, des bibliothèques d'algorithmes optimisés et des pilotes de périphériques aux systèmes d'exploitation en temps réel et aux outils de développement faciles à utiliser. Les plates-formes de référence axées sur l'audio (comme la plate-forme de module audio SHARC d'ADI, illustrée à la figure 5) qui accélèrent le temps de mise sur le marché sont une rareté pour les SoC, mais assez courantes dans le domaine des DSP audio autonomes.

Figure 5 : les DSP fournissent généralement une plate-forme de développement axée sur l'audio comme le module audio SHARC (SAM) illustré ici. (Source :Analog Devices)

La conception de systèmes acoustiques en temps réel implique une planification stratégique délibérée des ressources système et ne peut pas être simplement gérée en allouant une marge de traitement restante sur un SoC multitâche. Au lieu de cela, un DSP audio autonome optimisé pour le traitement à faible latence est susceptible d'entraîner une robustesse accrue, une diminution du temps de développement et une évolutivité optimale pour répondre aux besoins futurs du système et aux niveaux de performances.

Référence

[1] Paul Beckmann. « Processeurs SOC multicœurs :performances, analyse et optimisation ». Conférence internationale AES 2017 sur l'audio automobile, août 2017.

---

David Katz a 30 ans d'expérience dans la conception de systèmes analogiques, numériques et embarqués. Il est directeur de l'architecture des systèmes pour l'infodivertissement automobile chez Analog Devices, Inc. Il a publié à l'échelle internationale près de 100 articles sur le traitement embarqué et il a présenté plusieurs documents de conférence dans le domaine. Auparavant, il a travaillé chez Motorola, Inc., en tant qu'ingénieur de conception senior dans des groupes de modems câblés et d'automatisation d'usine. David détient à la fois un B.S. et un M.Eng. en génie électrique de l'Université Cornell. Il peut être contacté à [email protected].

---

Contenus associés :

• Mélanger le matériel et les logiciels pour un meilleur son
• Comment les processeurs audio Edge permettent l'intégration vocale dans les appareils IoT
• L'IA trouve sa voix dans la chaîne audio
• Les solutions ANC adaptatives offrent des capacités audio améliorées
• Considérations relatives à la conception des systèmes de commande vocale à faible consommation d'énergie permanents

Pour plus d'informations sur Embedded, abonnez-vous à la newsletter hebdomadaire d'Embedded.