Brevet FR3069344A1 — publié le 20190125

DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne un procédé et un dispositif de traitement d'éléments sonores (moteur audio) à commande selon le protocole internet protocol, (IF) multiplateforme, capable de fonctionner indifféremment avec une carte audio physique ou virtuelle. Elle s'applique, en particulier, au traitement d'éléments sonores pour la radiodiffusion. ETAT DE LA TECHNIQUE Plusieurs problèmes se posent pour la transmission d'éléments sonores sur un réseau, par exemple internet. Le temps de latence ou période de latence représente le délai entre une action et le déclenchement d'une réaction, à savoir un retardement. En informatique et plus spécifiquement sur les réseaux informatiques, la latence, aussi appelée lag, est le délai entre le moment où une information est envoyée et celui où elle est reçue. Lorsque plusieurs paquets de données représentent des éléments sonores d'un même ensemble sonore, par exemple une chanson, le temps de latence doit être suffisamment uniforme pour que l'ensemble sonore puisse être diffusé au fur et à mesure de la réception de ces paquets. Obtenir un débit de données suffisant pour assurer une bonne qualité sonore est un autre problème à résoudre. L'emballement de paquets, c'est-à-dire l'arrivée 20 simultanée d'un grand nombre de paquets de données, risque de provoquer une saturation des circuits de réception des paquets. Disposer de la quantité de ressources de calcul (temps CPU) nécessaire au traitement des paquets de données, sans empêcher les autres processus informatiques de se dérouler correctement est un autre problème à résoudre. 25 Les solutions actuellement connues ne peuvent satisfaire les contraintes professionnelles, par exemple dans le domaine de la radiodiffusion. OBJET DE L'INVENTION La présente invention vise à remédier à tout ou partie de ces inconvénients. 2 A cet effet, selon un premier aspect, la présente invention vise un procédé de transmission de paquets de données, qui comporte : - une étape de réception de paquets de données codés multiplexés, - une étape de mise en mémoire tampon de paquets de données reçus, 5 - une étape de mesure de la quantité de ladite mémoire tampon occupée et - une étape de requête d'allocation de ressources de traitement d'au moins un paquet de données dans la mémoire tampon, en fonction de la mesure de la quantité de mémoire tampon occupée. Dans des modes de réalisation, les paquets de données codés multiplexés sont 10 horodatés, le procédé comportant, de plus, une étape de requête d'allocation de ressources de traitement, en fonction de l'horodatage d'au moins un paquet de données dans la mémoire tampon. Dans des modes de réalisation, le procédé comporte, de plus, une étape de démultiplexage d'au moins un paquet de données codés multiplexé lorsque les 15 ressources demandées sont allouées. Dans des modes de réalisation, le procédé comporte, de plus, une étape de décodage d'au moins un paquet de données codés démultiplexé lorsque les ressources demandées sont allouées. Dans des modes de réalisation, le procédé comporte, de plus, une étape de requête d'allocation de mémoire pour les données décodées. Dans des modes de réalisation, le procédé comporte la mise en oeuvre d'un orchestrateur sur le réseau, interface entre des éditeurs ou diffuseurs audios et des dispositifs de traitement d'éléments sonores. Dans des modes de réalisation, les commandes reçues et transmises par l'orchestrateur sont conformes au protocole internet. Dans des modes de réalisation, l'orchestrateur crée dynamiquement des conteneurs de dispositifs de traitement d'éléments sonores. Dans des modes de réalisation, l'orchestrateur crée, dimensionne et configure dynamiquement des services de traitement d'éléments sonores. Dans des modes de réalisation, le procédé comporte une étape de détermination de latence de transmission d'au moins une partie des paquets de données et une étape de correction de latence prenant en compte la variation du nombre de paquets reçus. 3 Dans des modes de réalisation, le procédé comporte une étape d'apprentissage de latence et de changement de débit de données émises en fonction de la latence. BREVE DESCRIPTION DES FIGURES 5 D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif en regard des dessins annexés, dans lesquels : - la figure 1 représente, sous forme de logigramme, des étapes de communication relatives à une commande de lecture (« Play ») entre des 10 éléments d'un système de communication sur un réseau, - la figure 2 représente, sous forme de logigramme, des étapes de communication relatives à une commande d'enregistrement (« record ») entre des éléments d'un système de communication sur un réseau, - la figure 3 représente, sous forme de logigramme, des étapes de 15 communication relatives à une commande de génération d'un master (« GenMaster ») entre des éléments d'un système de communication sur un réseau, - la figure 4 représente, sous forme de logigramme, des étapes de gestion de mémoires tampon de démultiplexeur et de décodeur, 20 - la figure 5 représente, schématiquement, un réseau muni d'un orchestrateur, - la figure 6 représente, en schéma-bloc, les fonctions mises en oeuvre pour un enregistrement avec une entrée ligne, - la figure 7 représente, en schéma-bloc, les fonctions mises en oeuvre pour 25 un enregistrement avec une entrée de flux internet, - la figure 8 représente, en schéma-bloc, les fonctions mises en oeuvre pour une lecture avec une sortie Icecast et Mpeg2Ts (marques déposées) et - la figure 9 représente, en schéma-bloc, les fonctions mises en oeuvre pour une lecture avec une sortie sur haut-parleur. 30 DESCRIPTION D'EXEMPLES DE REALISATION DE L'INVENTION La présente invention concerne un dispositif de traitement d'éléments sonores (moteur audio) à commande IP multiplateforme, capable de fonctionner 4 indifféremment avec une carte audio physique ou virtuelle. Une carte audio selon l'invention peut se commander avec une interface Xml unique pour : - faire un enregistrement sonore avec un encodage en temps réel aussi bien avec carte audio physique que virtuelle, 5 - diffuser un son en le décodant et réencodant si nécessaire sur une carte physique ou un flux IF en différents format (Mpeg2ts, Rtp raw, Mpeg etc), - faire de l'édition d'éléments sonores (génération de master) et - faire de la conversion de format. En termes d'environnement de fonctionnement, la carte audio selon l'invention 113 peut fonctionner en service, dans un conteneur docker, ou dans le cloud de type Aws ou Azure, sur Windows ou Linux sur architecture Intel ou Arm. L'orchestrateur de la carte audio fait la liaison entre les cartes audio et les programmes de type éditeur audio (RadioAssist, MediaAssist), diffuseur audio (AirPlayList, Ddo) dans les différents environnements (Windows, Docker, cloud). 15 Dans un environnement docker, l'orchestrateur est capable de créer dynamiquement les conteneurs de carte audio. Dans un environnement docker, Swarm, l'orchestrateur est capable de créer ou de mettre à l'échelle (« scaler ») un service de carte audio en donnant dynamiquement la configuration requise. 20 En ce qui concerne l'envoi et la réception de commandes Xml : Toute nouvelle session commence par une commande synchrone « OpenSession » qui crée un service de carte audio avec en retour un numéro d'identification unique qui servira tous au long de la session. Les commandes sont divisées en différentes catégories : 25 Les commandes de type lecture, ou « Play » (StartPlay, PausePlay, stopPlay) sont de type asynchrone. Les commandes de type enregistrement ou « Record » (StartRecord, PauseRecord, StopRecord) sont de type asynchrone. La commande d'édition d'élément sonore GenMaster est de type asynchrone. 30 La commande d'obtention de statut de lecture « GetStatusPlay » est de type synchrone et obtient le statut du lecture « play » (Idle, pause, play ou numéro de l'erreur) de la carte audio au moment de l'envoi. 5 La commandes d'obtention de statut d'enregistrement « GetStatusRecord » est de type synchrone et obtient le statut d'enregistrement (idle, pause, record ou numéro de l'erreur) de la carte audio au moment de l'envoi. La commande d'obtention de statut « GetStatus » est de type synchrone et 5 obtient le statut de la masterisation. La session se termine par une commande synchrone CloseSession qui détruit le service de carte audio. En ce qui concerne la réception selon le protocole internet (IF) : en réception IF, la carte audio détecte automatiquement le type de flux en entrée pour procéder au 10 démultiplexage et à la décompression en temps réel. La carte audio calcule la différence de temps entre chaque réception de trame IF pour calculer la dérive (« jitter ») du réseau. Ensuite, la carte audio se synchronise sur l'horloge du flux émetteur avec la correction du jitter ainsi que la prise en compte des variations du nombre de paquets reçu. 15 La carte audio selon l'invention possède une bufferisation multi-niveaux en réception IF. En premier niveau, le démultiplexeur bufferise l'excédent de paquets avant démultiplexage en cas de petite variation du flux en entrée pour privilégier une consommation réduite du temps CPU. En second niveau, dédié aux fortes variations du flux en entrée, le démultiplexeur obtient plus de temps CPU pour le démultiplexage 20 des paquets entrants et les transmet au décodeur qui stocke dynamiquement la trame Mpeg avant décodage En ce qui concerne la partie émission IF, la carte audio émettrice encode et envoie des trames Rtp et/ou Mpeg2ts avec un horodatage (timestamp). Si la partie réception est gérée par une autre carte audio selon l'invention, la carte audio réceptrice 25 calcule la variation entre les horodatages et renvoie le résultat à la carte audio émettrice, qui est capable par apprentissage (réseau de neurones de type ART) de changer le débit (dans la fourchette donnée à l'initialisation) au moment opportun pour s'adapter à la qualité du réseau. L'émetteur est capable aussi de renvoyer des paquets demandés par le 30 récepteur en cas de perte de données. On observe, en figure 1, des étapes de communication relatives à une commande de lecture (« play ») entre des éléments d'un système de communication sur un réseau. Les dispositifs en jeu sont une application 11, un orchestrateur 12 et une carte audio. Avec un premier message 14 « OpenSession », l'application 11 6 requiert de l'orchestrateur 12 l'ouverture d'une session de communication avec une carte audio 13. L'orchestrateur 12 émet alors une requête 15 de création de carte audio au serveur (non représenté) qui l'hébergera. Après avoir été créée, la carte audio 13 retourne à l'orchestrateur 12 un message de confirmation de création. 5 L'orchestrateur 12 transmet alors à l'application 11 un message d'identification 16 de la carte audio. Dans la suite de la description, le message transmis par l'application 11 à l'orchestrateur 12, avec identifiant de la carte audio 13 puis le message de même contenu transmis de l'orchestrateur 12 à la carte audio, éventuellement sans identifiant 10 de la carte audio 13, possèdent la même référence numérique. De même pour les messages allant de la carte audio 13 à l'application 11, via l'orchestrateur 12. Lorsque l'application 11 requiert la lecture d'un élément sonore par la carte audio 13, l'application 11 adresse à l'orchestrateur 12 un message 17 de début de lecture « StartPlay ». L'orchestrateur 12 fait suivre ce message à la carte audio 13. 15 Lorsque l'application 11 requiert le statut de lecture d'une carte audio 13, l'application 11 adresse à l'orchestrateur 12 un message 18 de demande de statut « GetStatusPlay ». L'orchestrateur 12 fait suivre ce message à la carte audio 13. En réponse, la carte audio 13 retourne à l'application 11, via l'orchestrateur 12, un message de statut « Message Status » 19. 20 Lorsque l'application 11 requiert une pause de lecture d'une carte audio 13, l'application 11 adresse à l'orchestrateur 12 un message 20 de demande de pause « PausePlay ». L'orchestrateur 12 fait suivre ce message à la carte audio 13. Lorsque l'application 11 requiert le statut de lecture d'une carte audio 13, l'application 11 adresse à l'orchestrateur 12 un message 21 de demande de statut 25 REVENDICATIONS1. Procédé (70) de transmission de paquets de données, caractérisé en ce qu'il comporte : - une étape (71) de réception de paquets de données codés multiplexés, - une étape (76) de mise en mémoire tampon de paquets de données reçus, _ une étape (72) de mesure de la quantité de ladite mémoire tampon occupée et - une étape (74) de requête d'allocation de ressources de traitement d'au moins un paquet de données dans la mémoire tampon, en fonction de la mesure de la quantité de mémoire tampon occupée. 2. Procédé selon la revendication 1, dans lequel les paquets de données codés multiplexés sont horodatés, le procédé comportant, de plus, une étape de requête d'allocation de ressources de traitement, en fonction de l'horodatage d'au moins un paquet de données dans la mémoire tampon. 3. Procédé selon l'une des revendications 1 ou 2, qui comporte, de plus, une étape de démultiplexage d'au moins un paquet de données codés multiplexé lorsque les ressources demandées sont allouées. 4. Procédé selon la revendication 3, qui comporte, de plus, une étape de décodage 20 d'au moins un paquet de données codés démultiplexé lorsque les ressources demandées sont allouées. 5. Procédé selon la revendication 4, qui comporte, de plus, une étape de requête d'allocation de mémoire pour les données décodées. 25 6. Procédé selon l'une des revendications 1 à 5, qui comporte la mise en oeuvre d'un orchestrateur sur le réseau, interface entre des éditeurs ou diffuseurs audios et des dispositifs de traitement d'éléments sonores. 30 7. Procédé selon la revendication 6, dans lequel les commandes reçues et transmises par l'orchestrateur sont conformes au protocole internet. 14 8. Procédé selon l'une des revendications 6 ou 7, dans lequel l'orchestrateur crée dynamiquement des conteneurs de dispositifs de traitement d'éléments sonores. 9. Procédé selon l'une des revendications 6 à 8, dans lequel l'orchestrateur crée, 5 dimensionne et configure dynamiquement des services de traitement d'éléments sonores. 10. Procédé selon l'une des revendications 1 à 9, qui comporte une étape de détermination de latence de transmission d'au moins une partie des paquets de 10 données et une étape de correction de latence prenant en compte la variation du nombre de paquets reçus. 11. Procédé selon la revendication 10, qui comporte une étape d'apprentissage de latence et de changement de débit de données émises en fonction de la latence.