🙅🏻 😚 🌓 Comment nous testons les systèmes de microphones sur STM32: l'expérience des développeurs d'appareils Yandex 🚃 🏡 🦄

Bonjour, je suis Gennady "Crail" Kruglov de l’équipe des solutions matérielles Yandex.

La sélection de microphones pour la matrice de microphones est une partie complexe et intéressante de notre travail: nous testons des modèles avec différents paramètres, expérimentons différentes configurations de matrice et améliorons les algorithmes de traitement du son.

Il est pratique pour les développeurs qui créent des algorithmes de réduction d’écho et de bruit non seulement de traiter des données brutes précédemment extraites d’un appareil en laboratoire, mais aussi d’interagir, par exemple, avec une nouvelle matrice de microphone en temps réel en la connectant à leur ordinateur portable.

Cela ne semble simple qu'à première vue. Dans cet article, je vais expliquer comment nous avons résolu le problème du transfert du son de sept microphones avec une interface PDM vers un ordinateur via USB, quelles nuances matérielles et logicielles nous avons rencontrées et comment les surmonter (spoiler: cette approche peut être adaptée pour les matrices avec le nombre de microphones ≤ 8 ) À la fin de l'article, je partagerai un lien vers le flux, où je montrerai le processus de développement sur le microcontrôleur STM32 et parlerai de la prochaine série.

Formulation du problème

Un peu de fond: pour créer un faisceau de sensibilité contrôlé, pour la première Yandex.Station, un circuit avec sept microphones (analogiques) a été sélectionné, pour la version Mini - avec quatre (déjà numériques). Pour les autres produits, différentes configurations sont envisagées, mais la matrice à sept microphones reste pour nous basique, classique.

Donc, étant donné: sept microphones numériques, la nécessité de les tester. Trouver: pas trop difficile à mettre en œuvre et une manière flexible d'interagir avec eux. Il est logique de diviser la tâche en deux:

1. Obtenez les données des microphones.

2. Envoyez-les à un ordinateur.

Dans l'appareil fini, lorsque l'utilisateur contacte Alice, les signaux des microphones numériques sont envoyés directement au processeur central (il est plus correct de l'appeler SoC - System-on-Chip, mais le «processeur» est plus familier et pratique), il dispose d'une puissance suffisante pour les traiter. Mais pour les algorithmes de débogage, il est beaucoup plus pratique d'obtenir ces données directement sur l'ordinateur du développeur. La façon la plus simple est de se connecter via USB: ainsi, la carte doit avoir un microcontrôleur avec l'unité appropriée. Nous aimons le contrôleur STM32, mais il est impossible d'envoyer directement le flux sonore des microphones: il n'y a pas d'unité de réception de signal PDM (modulation de densité d'impulsion) - l'interface de sortie des microphones numériques.

Une autre option consiste à connecter la carte du microphone à la carte de débogage du fabricant du SoC utilisé. Mais cette décision est liée à Linux alsamixer, et ses paramètres affectent fortement le résultat de la conversion de PDM en PCM. Ces blocs peuvent différer non seulement pour les processeurs de différents fabricants, mais même pour deux modèles du même fournisseur. Je vous rappelle que nous avions besoin d'une solution simple, transparente et prévisible.

Solution matérielle

Acceptez l'incapacité du STM32 à accepter le PDM multicanal. On pourrait utiliser le bloc SPI pour recevoir un signal PDM, mais un seul microphone peut être connecté à un bus SPI. Nous travaillons avec le contrôleur STM32L476RC, où il n'y a que trois bus de ce type. Complexité supplémentaire: le signal PDM est assez haute fréquence, il est nécessaire de faire sa décimation, la moyenne, le traitement, le filtrage - pour sept microphones, cette tâche est assez compliquée.

Puisque nous parlons d'une carte de débogage, et non d'un prototype pour la production de masse, nous nous concentrerons sur une puce spécialisée TSDP18xx. Il fait tout ce qui est nécessaire: il génère les fréquences et les signaux nécessaires pour PDM, fait la moyenne et traite le signal PDM, le transforme tout en un signal I2S. Plus précisément, TDM (Time Division Multiplexing), car le bus I2S suppose deux canaux, et si vous conduisez plus via les mêmes fils, il n'est plus tout à fait correct de l'appeler I2S.

L'avantage de cette approche est que tout le travail de préparation et de calcul de la moyenne est effectué par le TSDP. Moins - tous les algorithmes sont étroitement câblés à l'intérieur de ce microcircuit, et ils ne peuvent pas être modifiés. En particulier, vous ne pouvez pas régler le volume en modifiant les paramètres de moyenne. Mais pour le débogage, ce n'est pas critique.

Surveillez vos mains: il y a sept microphones, huit canaux sur le microcircuit. Celui qui n'est pas utilisé, la sortie est toujours là, donc à l'avenir pour plus de simplicité, je parlerai du flux audio à huit canaux.

Donc, nous élevons le TDM à huit canaux en STM32, nous obtenons un flux audio à huit canaux. Comment les données se déplacent:

unité matérielle SAI - STM32 pour travailler avec I2S / TDM. Il est très flexible et vous permet de mettre en œuvre de nombreuses options de protocole. Mais à cause de cela, il est facile de se confondre avec les exigences de fréquences.

L'arbre à horloge mérite un examen plus approfondi. Un résonateur à quartz de 12 MHz est connecté au microcontrôleur. Nous divisons cette fréquence avant d'appliquer aux blocs PLL par 3 et obtenons 4 MHz. Ensuite, cela fonctionne comme ceci:

1. Ce serait bien d'augmenter la fréquence de base pour suivre tout: par exemple, le maximum pour ce contrôleur est de 80 MHz. Nous utilisons le premier bloc PLL: nous multiplions 4 MHz par 40 et divisons par 2.

2. L'USB nécessite 48 MHz. Pour ce faire, utilisez le deuxième bloc PLL: multipliez 4 MHz par 24 et divisez par 2.

3. À propos des microphones. Nos cartes de test utilisent une fréquence d'échantillonnage de Fs = 16 kHz, une norme adoptée dans le domaine de la reconnaissance vocale. À partir de la fréquence initiale de 4 MHz, vous devez obtenir quelque chose qui peut être transformé en fréquences de trame de bus TDM 16 kHz (alias LRCK, alias FCK, alias FrameSync). Dans ce cas:

[fréquence de synchronisation des bits (BCLK, BitClk, Sync, SCK)] = Fs ∙ [nombre de canaux] ∙ [nombre de bits par canal]

Soit: SCK = 16 kHz ∙ 8 ∙ 16 = 2048 kHz.

4. La fiche technique indique que la relation entre l'horloge maître et la fréquence d'échantillonnage Fs est la suivante: MasterClock = 16 kHz ∙ Diviseur MCLK ∙ 256. Ici, 256 est une constante et le diviseur peut être réglé dans le registre. Vérifions le schéma - pour la fonctionnalité nécessaire, il existe des coefficients pour diviser la fréquence PLL par 7 ou 17:

Pour résumer le problème: vous devez sélectionner un tel ensemble de facteurs et diviseurs PLL et SAI pour obtenir une fréquence d'échantillonnage de 16 kHz et une fréquence binaire de 128 fois plus. Étant donné que l'ensemble avait un diviseur obligatoire de 7 (ou 17), il n'a pas fonctionné pour obtenir exactement le résultat souhaité. J'ai dû construire une table de multiplicateurs et de diviseurs pour obtenir 24,571 MHz. En divisant cette fréquence par 6 (diviseur MCLK), puis par 256 (constant), enfin, nous obtenons un nombre assez proche de 16 kHz. Je vais maintenant expliquer pourquoi cela est si important.

Fonctionnement USB

L'USB utilise un type de transfert isochrone pour travailler avec des données multimédia: dans ce cas, une certaine bande passante et une certaine valeur de retard sont garanties sur le bus USB. La livraison des données n'est pas garantie: si un paquet arrive avec une panne, il sera alors considéré comme perdu. Cela est dû à des délais stricts: il n'y a aucun moyen de demander à nouveau.

Avec le type de transfert isochrone à la vitesse USB FullSpeed (c'est 12 Mbit / s; c'est à cette vitesse que le bloc USB STM32 peut fonctionner), l'ordinateur arrive à l'appareil pour les données toutes les millisecondes: après cette période de temps, il doit collecter les données accumulées. Permettez-moi de vous rappeler les introductions: la fréquence d'échantillonnage est de 16 kHz, 8 canaux, chaque canal nécessite deux octets, car le son est de seize bits. Total 16000 ∙ 2 ∙ 8/1000 = 256 octets par milliseconde. La taille d'un paquet pour un type de transmission isochrone peut atteindre 1023 octets, il n'y a donc aucun problème à ce stade.

Ainsi, la taille du paquet est de 256 octets. Il semblerait que tout va bien. Seize fois reçu des données sur TDM, mises dans le buffer, l'USB est venu, nous lui donnons un paquet, nous répétons ... Mais cela n'arrive que dans un monde idéal. Le problème est que, d'une part, nous avons une fréquence imparfaite de 16 kHz (un peu moins) et, par conséquent, les données arrivent un peu moins d'une fois par milliseconde. D'un autre côté, la milliseconde de l'ordinateur flotte également, car il est occupé: quand il le pouvait, alors il est venu. Autrement dit, la fréquence d'échantillonnage du microphone diffère de 16 kHz (mais toujours la même), et la milliseconde USB diffère également en longueur (la différence flotte probablement: elle s'avère un peu plus, puis un peu moins qu'une milliseconde idéale).

Pourquoi c'est un problème? Vous pouvez perdre le colis. Il n'est probablement pas nécessaire d'expliquer que des données complètes sont nécessaires pour le débogage correct des algorithmes. Comment le paquet est perdu: ils ont accumulé 256 octets de résultats, les ont mis dans le tampon et ont continué la mesure. Un ordinateur est venu, a pris les 256 premiers, nous continuons toujours de mesurer. L'ordinateur est revenu, mais la mesure n'est pas encore terminée - l'ordinateur est parti avec un emballage vide. Ensuite, nous finissons de remplir le tampon et commençons à en remplir un autre, le suivant, jusqu'à ce que l'ordinateur arrive à nouveau. L'ordinateur ne prend que le dernier paquet; par conséquent, un paquet est perdu.

Le problème est en effet connu. Il existe trois approches pour y faire face:

. USB. — . «» — . USB . , , ( , 16 ), . , .
. .
L'asynchrone est le meilleur pour cette tâche. L'appareil dispose d'un générateur de fréquence stable. Le taux d'échantillonnage est maintenu exactement le même sans référence à l'USB. Dans ce cas, vous devez transférer des données vers l'appareil afin qu'il n'y ait pas d'anomalies significatives.

Tout cela a été discuté plus d'une fois sur Internet pour le cas de la lecture d'un ordinateur vers le haut-parleur via un appareil avec un codeur numérique-analogique, où l'appareil en tant que rétroaction vous indique combien de périodes d'échantillonnage se sont produites depuis la réception du dernier paquet.

Mais notre tâche est l'inverse, le débogage nécessite de recevoir des données des microphones vers un ordinateur, et la question de l'enregistrement d'un signal des microphones vers un ordinateur n'est mentionnée que dans le meilleur des cas. Pourquoi ne pas faire de même: introduire les commentaires de l'ordinateur? Il existe une option plus simple.

Le voilà

Nous utilisons l'ajout fréquent d'échantillons et de deux tampons pour stocker les données à envoyer. 16 fois par milliseconde, nous ajoutons au tampon sélectionné l'échantillon suivant. À un moment donné, une interruption se produit: USB a pris le paquet précédent. Si le tampon n ° 1 est plein, il passe au tampon n ° 2. Lorsque l'USB arrive pour le prochain paquet, il est déjà préparé. Envoyez le tampon numéro 2 et revenez au numéro 1.

L'USB vient pour les données à différents moments, le forfait comprend un nombre différent d'échantillons. Il peut s'avérer être supérieur ou inférieur à seize, il y a donc une chance de dépasser un paquet de 256 octets, il est préférable de laisser un espace de manœuvre. Soit 384 = 256 + 128: cela donnera une marge d'une demi-milliseconde, c'est-à-dire qu'il pardonnera la phase de nage du signal USB de 50% - une telle marge devrait être plus que suffisante. Total: parfois plus ou moins 256 octets sont envoyés, mais jamais un paquet vide, ce qui évite la perte de données. C'est-à-dire que le problème des irrégularités a été résolu en augmentant le package, au prix d'augmenter une partie de la bande passante du bus allouée à notre appareil et de réduire cette partie pour d'autres appareils.

Sur ce point, la livraison des données à l'ordinateur a pris fin. Les développeurs peuvent être débogués et vous pouvez poser des questions dans les commentaires si une sorte de paquet de données n'était pas suffisant pour une compréhension complète.

Mes streams et le prochain épisode

Dernièrement, j'ai diffusé deux fois depuis mon laboratoire de soudage à domicile. Au début, je viens de montrer le processus de soudage et de dire quels appareils j'utilise. La deuxième série vient d'être consacrée au développement sur le STM32.

Les flux continuent. Ce vendredi à 19h00, mon collègue de l'équipe de développement de solutions matérielles Andrey Laptev organisera une analyse en ligne de Yandex.Stations Mini - montrez l'intérieur et partagez les historiques de production. Pour plus de plaisir, Andrey va visser la batterie à la colonne - pas tout de même, travailler à partir du fil. Au final, vous recevrez un guide qui vous permettra de répéter cette expérience vous-même ou de proposer un design plus intéressant.

S'inscrirepour regarder le flux. Vous recevrez une lettre avec un dossier pour le calendrier et un rappel le jour de l'air. Merci pour la lecture!

Comment nous testons les systèmes de microphones sur STM32: l'expérience des développeurs d'appareils Yandex

Formulation du problème

Solution matérielle

Fonctionnement USB

Le voilà

Mes streams et le prochain épisode

More articles: