Téléphone SIP sur STM32F7-Discovery

Bonjour à tous.

Il y a quelque temps, nous ont écrit avons réussi à faire fonctionner un téléphone SIP sur STM32F4-Discovery avec 1 Mo de ROM et 192 Ko de RAM) basé sur Embox. Il faut dire que cette version était minimale et connectait deux téléphones directement sans serveur, et le transfert de voix n'était qu'unidirectionnel. Nous avons donc décidé de lancer un téléphone plus complet, capable de passer des appels via un serveur, avec une transmission de voix dans les deux sens, tout en optimisant l'utilisation de la mémoire.

Pour le téléphone, nous avons choisi l'application simple_pjsua faisant partie de la bibliothèque PJSIP. C'est une application minimale qui peut s'enregistrer sur un serveur, recevoir et répondre à des appels. Ci-dessous, je vais tout de suite décrire comment la lancer sur STM32F7-Discovery.

Comment démarrer

1. Configurer Embox

   make confload-platform/pjsip/stm32f7cube

2. Dans le fichier conf/mods.config, définissez le compte SIP nécessaire.

   
   include platform.pjsip.cmd.simple_pjsua_imported(
       sip_domain="server", 
       sip_user="username",
       sip_passwd="password")
   

   où serveur — c'est le serveur SIP (par exemple, sip.linphone.org), username et password — le nom d'utilisateur et le mot de passe du compte.

3. Nous construisons Embox avec la commande make. Nous avons des informations sur le flashage de la carte sur wiki et dans article.
4. Lancez la commande Embox “simple_pjsua_imported” dans la console

   
   00:00:12.870    pjsua_acc.c  ....Le statut sortant SIP pour acc 0 n'est pas actif
   00:00:12.884    pjsua_acc.c  ....sip:alexk2222@sip.linphone.org: enregistrement réussi, statut=200 (Enregistrement réussi
   00:00:12.911    pjsua_acc.c  ....Le minuteur de maintien actif a été démarré pour acc 0, destination:91.121.209.194:5060, intervalle:15s
   

5. Enfin, il reste à brancher des haut-parleurs ou des écouteurs à la sortie audio, et à parler dans deux petits microphones MEMS près de l'écran. Appelons depuis Linux via l'application simple_pjsua, pjsua. Ou nous pourrions utiliser n'importe quelle autre application comme linphone.

Tout cela est décrit sur notre wiki.

Comment nous y sommes arrivés

Alors, la question initiale était de choisir une plateforme matérielle. Étant donné que nous savions que le STM32F4-Discovery ne convenait pas en termes de mémoire, nous avons opté pour le STM32F7-Discovery. Celui-ci dispose de 1 Mo de flash et de 256 Ko de RAM (+ 64 Ko de mémoire rapide spéciale, que nous allons également utiliser). Ce n'est pas beaucoup pour des appels via un serveur, mais nous avons décidé de tenter le coup.

Nous avons conditionnellement divisé la tâche en plusieurs étapes :

• Démarrer PJSIP sur QEMU. Cela était pratique pour le débogage, plus nous avions déjà un support pour le codec AC97.
• Enregistrement de la voix et reproduction sur QEMU et sur STM32.
• Portage de l'application simple_pjsua de la bibliothèque PJSIP. Elle permet de s'enregistrer sur un serveur SIP et de passer des appels.
• Déployer votre propre serveur basé sur Asterisk et tester dessus, avant d'essayer des externes, comme sip.linphone.org.

Le son dans Embox fonctionne via Portaudio, qui est également utilisé dans PISIP. Quelques problèmes sont apparus sur QEMU — les fichiers WAV à 44100 Hz se sont bien joués, mais à 8000, quelque chose ne fonctionnait clairement pas. Il s'est avéré que le problème venait de la configuration de la fréquence — par défaut, dans le matériel, elle était à 44100, et cela n'a pas été changé par logiciel.

Il convient peut-être d'expliquer un peu comment se déroule la lecture du son. Une carte audio peut se voir attribuer un pointeur vers une zone mémoire, à partir de laquelle il faut lire ou enregistrer à une fréquence préétablie. Une fois que le tampon est épuisé, une interruption est générée, et l'exécution reprend avec le tampon suivant. Le fait est qu'il faut remplir ces tampons à l'avance, tant que le précédent est en cours de lecture. Nous allons rencontrer ce problème plus tard sur STM32F7.

Ensuite, nous avons loué un serveur et déployé Asterisk dessus. Comme il fallait déboguer beaucoup et que nous ne souhaitions pas parler dans le microphone, nous devions mettre en place une lecture et un enregistrement automatiques. Pour cela, nous avons patché simple_pjsua afin de pouvoir insérer des fichiers à la place des périphériques audio. Dans PJSIP, cela se fait assez simplement, car ils ont le concept de port, qui peut être à la fois un périphérique et un fichier. Et ces ports peuvent être connectés de manière flexible à d'autres ports. Vous pouvez consulter le code dans notre pjsip. dépôts. En fin de compte, le schéma était le suivant. Sur le serveur Asterisk, j'ai créé deux comptes — un pour Linux et un pour Embox. Ensuite, sur Embox, la commande est exécutée simple_pjsua_imported, Embox s'enregistre sur le serveur, puis nous appelons Embox depuis Linux. Au moment de la connexion, nous vérifions sur le serveur Asterisk que toute la connexion est établie, et après un certain temps, nous devrions entendre le son provenant de Linux dans Embox, et sur Linux, nous sauvegardons le fichier qui est joué depuis Embox.

Une fois que cela a fonctionné sur QEMU, nous sommes passés à la portabilité sur STM32F7-Discovery. Le premier problème — nous ne tenions pas dans 1 Mo de ROM sans activer l'optimisation du compilateur “-Os” pour réduire la taille de l'image. Donc, nous avons activé “-Os”. Ensuite, nous avons désactivé le support de C++ par patch, car cela n'est nécessaire que pour pjsua, et nous utilisons simple_pjsua.

Une fois que nous avons réussi à intégrer simple_pjsua, nous avons décidé que les chances de le lancer étaient désormais réelles. Mais d'abord, il fallait se pencher sur l'enregistrement et la lecture de la voix. La question se posait — où enregistrer ? Nous avons choisi la mémoire externe — SDRAM (128 Mo). Vous pouvez essayer vous-même :

Créera un WAV stéréo à 16000 Hz et d'une durée de 10 secondes :

record -r 16000 -c 2 -d 10000 -m C0000000

Lecture :

play -m C0000000

Il y avait deux problèmes. Le premier concernait le codec — le WM8994, qui a un concept de slot, et il y a quatre slots. Par défaut, si ce n'est pas configuré, lors de la lecture audio, cela se produit dans les quatre slots. Donc, à 16000 Hz, nous obtenions 8000 Hz, et pour 8000 Hz, la lecture ne fonctionnait tout simplement pas. Quand nous avons choisi uniquement les slots 0 et 2, cela a bien fonctionné. Un autre problème était l'interface audio dans STM32Cube, où la sortie audio fonctionne via SAI (Serial Audio Interface) synchronisée avec l'entrée audio (je n'ai pas approfondi les détails, mais il semble qu'ils partagent un horloge commune et lors de l'initialisation de la sortie audio, l'entrée audio s'y attache d'une certaine manière). Donc, ils ne peuvent pas être lancés séparément, c'est pourquoi nous avons fait ce qui suit — l'entrée audio et la sortie audio fonctionnent toujours (y compris la génération d'interruptions). Mais quand rien n'est joué dans le système, nous fournissons simplement un tampon vide à la sortie audio, et quand la lecture démarre, nous commençons à le remplir correctement.

Ensuite, nous avons rencontré le problème que le son lors de l'enregistrement de la voix était très faible. Cela se produit parce que les microphones MEMS sur l'STM32F7-Discovery fonctionnent mal à des fréquences inférieures à 16000 Hz. Nous réglons donc à 16000 Hz, même s'il arrive à 8000 Hz. Pour cela, il a fallu ajouter une conversion logicielle d'une fréquence à une autre.

Nous avons ensuite dû augmenter la taille du tas, qui se trouve dans la RAM. Selon nos calculs, pjsip nécessitait environ 190 Ko, tandis que nous n'avions plus qu'environ 100 Ko disponibles. Nous avons donc dû utiliser un peu de mémoire externe — SDRAM (environ 128 Ko).

Après toutes ces modifications, j'ai vu les premiers paquets entre Linux et Embox, et j'ai entendu du son ! Mais le son était horrible, rien à voir avec QEMU, et rien n'était compréhensible. Nous nous sommes donc demandé quelle pouvait être la cause. Le débogage a montré qu'Embox avait simplement du mal à remplir/vider les tampons audio. Pendant que pjsip traitait un cadre, deux interruptions de fin de traitement des buffers se produisaient, ce qui était trop. La première idée pour accélérer le processus était l'optimisation du compilateur, mais elle était déjà activée dans PJSIP. Deuxièmement — le point flottant matériel, dont nous avons parlé dans article. Mais comme l'expérience l'a montré, le FPU n'a pas apporté de gain de vitesse significatif. La prochaine étape a été de définir les priorités des flux. Dans Embox, il existe différentes stratégies de planification, et j'ai activé celle qui prend en charge les priorités, attribuant la priorité la plus élevée aux flux audio. Cela n'a pas non plus aidé.

L'idée suivante était que nous travaillons avec de la mémoire externe et qu'il serait donc judicieux d'y déplacer les structures auxquelles nous accédons très fréquemment. J'ai réalisé une analyse préliminaire sur le moment et le pourquoi simple_pjsua de l'allocation mémoire. Il s'est avéré que sur 190 Ko, les 90 premiers Ko sont alloués pour les besoins internes de PJSIP et sont accédés assez rarement. Ensuite, lors d'un appel entrant, la fonction pjsua_call_answer est appelée, où des tampons sont ensuite alloués pour travailler avec les trames entrantes et sortantes. Cela représentait encore environ 100 Ko. Et là, nous avons agi de la manière suivante. Avant l'appel, nous plaçons les données en mémoire externe. Dès que l'appel commence, nous remplaçons immédiatement le tas par un autre – en RAM. Ainsi, toutes les données « chaudes » ont été transférées vers une mémoire plus rapide et plus prévisible.

Au final, tout cela a permis de lancer simple_pjsua et d'appeler via son propre serveur. Puis, nous avons également pu le faire via d'autres serveurs comme sip.linphone.org.

Conclusions

En fin de compte, nous avons réussi à lancer simple_pjsua avec transmission vocale bidirectionnelle via le serveur. Le problème des 128 Ko de SDRAM supplémentaires peut être résolu en utilisant un Cortex-M7 un peu plus puissant (par exemple, STM32F769NI avec 512 Ko de RAM), mais pour l'instant, nous n'avons pas encore abandonné l'espoir d'entrer aussi dans 256 Ko 🙂 Nous serions ravis si quelqu'un s'intéresse, et encore mieux – essaie. Tous les sources, comme d'habitude, sont à notre disposition. dépôts.

Source : habr.com