Développer des solutions avec de l’audio est devenu bien plus accessible aujourd’hui, grâce à l’IA. Par exemple, capturer le signal audio d’un microphone et le transmettre à un modèle de classification, de détection ou de transcription sont des opérations qui nous semblent soudainement plus faciles à intégrer rapidement à une application avec l’aide de quelques instructions en langage naturel. Pour les ingénieurs qui abordent ce domaine sans être forcément des spécialistes voici quelques points de repère techniques et principes pour vous guider.
1. Comprendre le chemin d’acquisition du signal audio
De nombreux modèles (en parole notamment) attendent un signal audio mono 16kHz généralement en float32, mais ce n’est pas nécessairement ce que vous fournira le périphérique audio que vous utilisez. En effet, le flux audio peut être capturé initialement en stéréo 48kHz PCM 16bits, puis converti. Cela dépendra du matériel, du pilote, du serveur audio et de la bibliothèque utilisée.
Ces conversions ne sont pas nécessairement mauvaises en soi, mais savoir qu’elles peuvent avoir lieu et surtout dans quelles conditions est essentiel.
Enfin, il est important de vérifier les capacités du matériel d’acquisition avant de changer l’architecture du code. Par exemple, sur les systèmes Linux il existe plusieurs chemins de capture. Un accès direct via ALSA permet d’avoir un plus grand contrôle sur le périphérique audio et ses paramètres, mais il ne garantit ni la prise en charge, par le matériel, du format souhaité, ni l’absence de conversions dans la chaîne audio. Vérifiez donc les formats que supporte réellement le périphérique et voyez si la bibliothèque que vous utilisez permet de négocier une configuration donnée.
2. Comprendre ce qu’implique les transformations du signal
Le ré-échantillonnage d’un signal, le passage de la stéréo au mono et la conversion du PCM 16bits vers du float32 sont trois opérations différentes. Je vois trop souvent des pipelines audio où la réduction du taux d’échantillonnage consiste simplement en la suppression d’un échantillon sur trois. Aussi, si moyenner simplement deux canaux suffit la plupart du temps pour obtenir un signal mono, il existe certaines exceptions où cela peut entraîner une modification significative du signal.
La question n’est donc pas de savoir comment optimiser la chaîne de traitements en évitant toutes ces conversions, mais plutôt de savoir lesquelles sont nécessaires, à quel moment doivent-elles être effectuées et quel est leur coût en termes de calcul.
3. Chercher la latence là où elle se trouve réellement
Ne bornez pas vos recherches de la latence aux seuls traitements du signal audio. La latence peut s’accumuler partout, notamment dans les buffers, les queues, les copies en mémoire, la synchronisation des threads et enfin à l’inférence du modèle et dans les prétraitements audio. Alors certes, la conversion d’un signal peut s’avérer coûteuse, mais la détermination de la taille idéale des buffers ou l’amélioration de la gestion de la mémoire seront parfois plus bénéfiques en termes de performance.
Ainsi, bien qu’il soit important de mesurer la latence de bout en bout de votre pipeline et au niveau de chaque composant de votre chaîne de traitement, gardez en tête que la friction provient aussi de ces mécanismes cités précédemment qui nous permettent d’articuler ces différents composants.
4. Le rôle de l’ingénieur à l’ère du code généré par l’IA
Ceci étant dit, quel rôle peut jouer l’ingénieur dans tout ça, si l’IA est capable d’écrire du code fonctionnel ? En tant qu’ingénieur, il est vain de s’efforcer à vouloir maîtriser et connaître toutes les API sur le bout des doigts. L’enjeu pour l’ingénieur c’est de comprendre suffisamment le système pour savoir quoi mesurer et quelle question se poser. En effet, l’IA peut faciliter l’implémentation, mais si la solution qu’elle propose peut paraître cohérente, elle peut aussi être inadaptée aux contraintes réelles du système. Il est à noter que ce n’est pas le propre de l’IA, les ingénieurs aussi peuvent faire de mauvais choix. Mais c’est du fait que l’IA rend la production d’une implémentation cohérente et plausible très rapide que nous sommes incités à accepter (trop rapidement) ses choix.
Un réflexe qu’ont beaucoup d’ingénieurs (moi y compris) est de rejeter les abstractions et de réécrire les composants avec les briques logicielles de bas niveau. Le piège qu’il faut alors éviter c’est de se lancer dans une optimisation du code sur la base d’intuitions, quand bien même elles peuvent nous être utiles parfois, il est préférable d’agir en connaissance de cause. C’est donc le rôle de l’ingénieur de savoir quelles hypothèses vérifier et quelles mesures effectuer pour savoir à quel moment il est nécessaire de descendre d’une couche dans la pile d’abstraction logicielle pour ne pas sacrifier inutilement la simplicité d’usage et de maintenabilité d’une bibliothèque de plus haut niveau.
Comme vous l’aurez compris, cela ne se limite pas uniquement au domaine de l’audio. Nous avons basculé dans un monde où le code devient accessible à tous, l’expertise ne se mesure donc plus à ce que l’on sait écrire, mais plutôt à ce que l’on sait vérifier. Et plus encore : à savoir ce qu’il faut véritablement mesurer et si ces mesures répondent vraiment aux questions que l’on se pose.