Brevet FR3154564A1 — publié le 20250425

Synchronisation des échanges de flux audio lors d’une conférence audio L’invention se rapporte à un procédé de synchronisation de données audio lors d’une conférence audio entre une pluralité de participants via des dispositifs clients, le procédé étant mis en œuvre par un premier dispositif client de la conférence partageant un même espace commun qu’un second dispositif client et dans lequel les étapes suivantes sont exécutées : - échange (E23, E29) d’informations d’horodatage entre le dispositif client et un dispositif serveur connecté avec les dispositifs clients de l’espace commun ; - calcul (E24) d’une dérive d’horloge du dispositif client par rapport au dispositif serveur à partir des informations échangées ; - lors de la capture de données audio via un microphone du dispositif client, traitement (E25) des paquets audio capturés par rééchantillonnage des paquets selon la valeur de la dérive d’horloge calculée et transmission (E26) des paquets rééchantillonnés au dispositif serveur avec une information d’horodatage des paquets. L’invention se rapporte également à un procédé de traitement de données audio par un dispositif serveur. L’invention se rapporte à un dispositif client et à un dispositif serveur mettant en œuvre les procédés respectifs de synchronisation et de traitement. Figure de l’abrégé : Figure 2 Synchronisation des échanges de flux audio lors d’une conférence audio La présente invention se rapporte au domaine des conférences audio ou visio-conférence et plus particulièrement à l’amélioration de la qualité audio lorsque plusieurs personnes participantes à la conférence partagent un même environnement. Les systèmes de conférence (audio-conférence et visio-conférence) permettent de réaliser des réunions virtuelles entre personnes distantes. Du fait de la crise Covid, et des confinements associés, cet usage s’est répandu et aujourd’hui le télétravail régulier a rendu cet outil inévitable. Ces systèmes peuvent se présenter sous forme autonome pour équiper des salles de réunion dites dédiées, ou sous forme logicielle sur PC ou son téléphone mobile intelligent dit smartphone via des applications telles Teams®, Zoom® ou encore Skype® pour n’en citer que quelques-unes. Ces applications sont installées sur des dispositifs de communication comportant des modules logiciels appelés clients de conférence pilotant ce type d’application. Les dispositifs peuvent se connecter entre eux directement (en mode "pair à pair"), ou utilisent un pont de conférence, qui permet d’agréger les signaux des micros des participants, et de leur renvoyer un mixage audio individualisé (la somme de tous les micros sauf le sien). Dans le cas spécifique d’une réunion dite "hybride", c’est à dire une réunion impliquant au moins une salle de réunion et un ou plusieurs participants à distance (voire une ou d’autres salles de réunion à distance), une partie des participants (les co-participants) est colocalisée dans un même espace (la salle de réunion). Chacun des co-participants peut amener dans la salle son PC et/ou son smartphone pour se connecter individuellement à la réunion virtuelle afin de suivre les éléments visuels de la réunion (visio, présentation, …). Néanmoins, il est nécessaire qu’à l’exception d’un seul des co-participants, que nous appellerons co-participant principal, tous les co-participants désactivent leur micro et leur haut-parleur de leur dispositif respectif. En effet : - si l’un des co-participants (que nous appellerons co-participant secondaire) laisse son micro activé, les participants distants recevront les signaux audio de 2 micros (co-participant principal et secondaire) à des instants différents car les systèmes de conférence ne garantissent pas la synchronisation des sources sonores. Il en résulte une sensation d’écho intolérable du côté des participants à distance. Il est à noter que si les signaux micros des clients de conférence étaient synchronisés avec une précision inférieure à environ 50ms, la sensation d’écho deviendrait tolérable mais toujours audible, et quasiment inaudible en dessous de 20ms. Néanmoins, le haut-parleur du co-participant principal émettra le son capté par le micro du co-participant secondaire, créant ainsi un écho intolérable en salle de réunion (un participant en salle de réunion sera entendu en direct, puis à travers le haut-parleur du co-participant principal avec un retard de l’ordre de quelques centaines de ms). - si l’un des co-participants secondaires laisse son haut-parleur activé, tous les co-participants entendront les signaux audio des participants distants via les 2 haut-parleurs (co-participant principal et secondaire) à des instants différents. Il en résulte également une sensation d’écho intolérable du côté des co-participants. Les systèmes de conférence actuels ne garantissant pas la synchronisation des signaux sonores micro ni haut-parleur, le son de la salle de réunion n’est donc généralement capté que par le micro du co-participant principal, et le son des distants n’y est restitué que par le haut-parleur du co-participant principal. Il en résulte que les co-participants éloignés du co-participant principal : - seront difficilement compris par les participants distants, du fait de l’atténuation acoustique lié à leur distance au microphone, mais aussi du fait de la réverbération de la salle qui réduit les indices d’intelligibilité - comprendront difficilement les participants distants, du fait de l’atténuation acoustique lié à leur distance au haut-parleur, mais aussi du fait de la réverbération de la salle qui réduit les indices d’intelligibilité. Le document brevet US 11425258 tente de résoudre le problème d’écho en dédiant un des dispositifs d’un même espace ou bien le pont de conférence, à un traitement de synchronisation avancé des données qu’il reçoit des autres dispositifs de l’espace commun avant la transmission d’un flux mixé vers d’autres participants distants. Ce type de système focalise la charge de traitement sur un seul dispositif, ce qui peut être problématique pour l’équipement en question qui peut ne pas être prévu pour absorber une telle charge de traitement, surtout si le nombre de participants est important. D’autre part, la synchronisation mise en œuvre dans ce document est effectuée sur des données mémorisées dans la mémoire d’un dispositif commun, elle est donc basée sur une analyse de corrélation des signaux audio reçus et mémorisés afin d’obtenir les différences de temps entre les signaux, indépendamment des latences dues aux distances de propagation acoustique. Ce type d’analyse est couteux en termes de charge de traitement et manque de fiabilité puisqu’il repose sur des données audio qui peuvent être bruitées ou instables. Il existe donc un besoin d’améliorer les méthodes de l’état de l’art dans ce type de situation. L’invention vient améliorer l’état de la technique. A cet effet, l’invention vise un procédé de synchronisation de données audio lors d’une conférence audio entre une pluralité de participants via des dispositifs clients, le procédé étant mis en œuvre par un premier dispositif client de la conférence partageant un même espace commun qu’un second dispositif client et dans lequel les étapes suivantes sont exécutées : - échange d’informations d’horodatage entre le dispositif client et un dispositif serveur connecté avec les dispositifs clients de l’espace commun ; - calcul d’une dérive d’horloge du dispositif client par rapport au dispositif serveur à partir des informations échangées ; - lors de la capture de données audio via un microphone du dispositif client, traitement des paquets audio capturés par rééchantillonnage des paquets selon la valeur de la dérive d’horloge calculée et transmission des paquets rééchantillonnés au dispositif serveur avec une information d’horodatage des paquets. L’invention permet ainsi de pallier les problèmes d’intelligibilité des interventions de participants à une conférence audio qui peuvent apparaitre lorsque plusieurs participants à la conférence sont dans une même pièce et n’utilisent qu’un seul micro. Le procédé de synchronisation tel que décrit permet d’utiliser les micros des dispositifs clients, au plus proche de chacun des participants. Cette méthode répartit la charge de traitement sur les équipements clients plutôt que de la concentrer sur un seul équipement et apporte une synchronisation fiable des signaux audio, puisqu’elle s’effectue sur des informations d’horodatage qui sont des données fiables. Dans un mode de réalisation particulier, le procédé comporte en outre les étapes préalables suivantes : - activation d’une application de conférence ; - configuration des paramètres audio de l’application de conférence pour déconnecter une carte son interne pilotant au moins le microphone du dispositif client. Ces étapes préalables permettent de s’assurer que les données audio capturées par le micro du dispositif client ne sont pas transmises directement aux participants distants de la conférence. Ces données audio sont synchronisées par le procédé décrit ci-dessus avant d’être envoyées au dispositif serveur qui après traitement les enverra aux participants distants directement ou par l’intermédiaire d’un pont de conférence. Dans un mode complémentaire de réalisation, lors de la réception de données audio du dispositif serveur, le procédé met en œuvre une étape de conversion des données reçues par rééchantillonnage selon la valeur de la dérive d’horloge calculée et une étape de transmission des paquets rééchantillonnés à au moins un haut-parleur du dispositif client. Ainsi, les données audio sont restituées en utilisant les haut-parleurs des dispositifs clients, de façon synchronisée et au plus proche des participants utilisant ces dispositifs, elles sont donc plus compréhensibles. Dans un mode particulier de réalisation, l’échange d’informations d’horodatage s’effectue par des étapes d’envoi réguliers d’un paquet de données et de collecte de données d’heure d’envoi et de réception du paquet de données, sur une fenêtre temporelle. Ces échanges d’information d’horodatage permettent de mesurer le temps de propagation réseau entre un dispositif client et un dispositif serveur et ainsi obtenir les informations permettant la transformation de l’heure d’un dispositif sur un autre, ces échanges se faisant de façon régulière, ils permettent d’avoir une bonne précision des données de synchronisation au cours du temps pour adapter la synchronisation des données audio à un changement possible des conditions réseau. Dans un mode de réalisation particulier, le calcul de la dérive d’horloge entre le dispositif client et le dispositif serveur est effectué à partir des données d’heure collectées sur une fenêtre temporelle glissante et selon une fonction de régression linéaire appliquée aux données d’horodatage collectées lors des retours du paquet de données du dispositif serveur au dispositif client. Cette méthode de calcul permet d’obtenir de façon précise la dérive d’horloge entre les équipements, et permet ainsi d’ajuster moins souvent les valeurs de décalage d’horloge. Dans un mode de réalisation particulier, une fonction de régression linaire est également appliquée aux données d’horodatage collectées lors des allers du paquet de données du dispositif client au dispositif serveur. Cela permet de vérifier que le calcul sur les données de retour sont cohérentes avec le calcul effectué pour les données d’aller. Dans le cas contraire, un filtrage de la mesure problématique ou une correction de la valeur de la dérive pourra être appliquée. Dans une variante de réalisation la fonction de régression linaire est appliquée aléatoirement aux données d’horodatage collectées lors des retours ou bien des allers du paquet de données. Cette variante permet de s’affranchir des différences qui pourraient exister entre les données d’aller et les données de retour, par exemple des conditions réseau qui ne seraient pas identiques ou des conditions d’envoi et de réception qui seraient différentes. Dans un mode de réalisation, l’information d’horodatage des paquets audio rééchantillonnés est adaptée à l’horloge du dispositif serveur avant d’être envoyée au dispositif serveur. Ces données d’horodatage permettent ensuite au dispositif serveur de créer un flux mixé avec les différentes données rééchantillonnées reçues des différents dispositifs clients, sans avoir à effectuer de synchronisation supplémentaire. L’invention se rapporte également à un procédé de traitement de données audio lors d’une conférence audio entre une pluralité de participants via des dispositifs clients, le procédé étant mis en œuvre par un dispositif serveur connecté avec au moins un dispositif client partageant un même espace commun et dans lequel les étapes suivantes sont exécutées : - échange d’informations d’horodatage entre un dispositif client de l’espace commun et le dispositif serveur ; - lors de la réception de paquets de données audio avec des informations d’horodatage associées, en provenance des dispositifs clients de l’espace commun : - mémorisation des paquets dans une mémoire provisoire ; - alignement temporel des paquets mémorisés, en fonction des informations d’horodatage ; - mixage des paquets alignés pour obtenir un flux audio mixé ; - envoi du flux audio mixé à destination de participants distants de la conférence audio. Le procédé mis en œuvre par un dispositif serveur recevant des données synchronisées avec sa propre horloge permet de mixer les différentes données pour créer un flux à transmettre aux participants distants directement ou via un pont de conférence. Ce flux, une fois jouée par les différents haut-parleurs des participants distants, ne provoque pas les phénomènes d’écho qui peuvent apparaitre lorsque les données reçues sont non synchronisées. Selon un mode de réalisation, le procédé comporte en outre les étapes préalables suivantes : - activation d’une application de conférence ; - configuration des paramètres audio de l’application de conférence pour que les données audio d’entrée de l’application proviennent d’un module de traitement produisant le flux audio mixé. Ainsi, les signaux audio transmis par l’application de conférence vers les participants distants ou vers un pont de conférence ne proviennent pas directement des données audio captées par les micros des dispositifs de l’espace commun mais proviennent d’un module de traitement mettant en œuvre le procédé de traitement de données audio reçues des dispositifs clients de l’espace commun. Les signaux audio captés sont ainsi routés vers ce module de traitement afin d’obtenir un flux audio synchronisé à transmettre. L’invention se rapporte à un dispositif client partageant un même espace commun qu’un second dispositif client lors d’une conférence audio entre une pluralité de participants, le dispositif client comportant au moins un microphone piloté par une carte son interne, et au moins un module audio client piloté par un microprocesseur et apte à mettre en œuvre un procédé de synchronisation de données audio, le procédé comportant les étapes suivantes: - échange d’informations d’horodatage entre le dispositif client et un dispositif serveur connecté avec les dispositifs clients de l’espace commun ; - calcul d’une dérive d’horloge du dispositif client par rapport au dispositif serveur à partir des informations échangées ; - lors de la capture de données audio via le au moins un microphone du dispositif client, traitement des paquets audio capturés par rééchantillonnage des paquets selon la valeur de la dérive d’horloge calculée et transmission des paquets rééchantillonnés au dispositif serveur avec une information d’horodatage des paquets. Dans un mode de réalisation, le dispositif comporte en outre un module client de conférence apte à activer une application de conférence, la carte son interne étant configurée comme étant déconnectée du module client de conférence pour l’application de conférence. Le dispositif client a les mêmes avantages que le procédé de synchronisation qu’il met en œuvre. L’invention se rapporte aussi à un dispositif serveur connecté avec au moins un dispositif client partageant un même espace commun lors d’une conférence audio entre une pluralité de participants, le dispositif serveur comportant au moins un module audio serveur piloté par un microprocesseur et apte à mettre en œuvre un procédé de traitement de données audio, le procédé comportant les étapes suivantes: - échange d’informations d’horodatage entre un dispositif client de l’espace commun et le dispositif serveur ; - lors de la réception de paquets de données audio avec des informations d’horodatage associées, en provenance des dispositifs clients de l’espace commun : - mémorisation des paquets dans une mémoire provisoire ; - alignement temporel des paquets mémorisés, en fonction des informations d’horodatage ; - mixage des paquets alignés pour obtenir un flux audio mixé ; - envoi du flux audio mixé à destination de participants distants de la conférence audio. Selon un mode de réalisation, le dispositif serveur comporte un module client de conférence apte à activer une application de conférence et au moins une carte son virtuelle configurée comme entrée des données audio du module client de conférence de la conférence audio, la carte son virtuelle recevant le flux audio mixé du module audio serveur. Le dispositif serveur a les mêmes avantages que le procédé de traitement qu’il met en œuvre. L’invention vise un terminal comportant un dispositif client et/ou un dispositif serveur tels que décrits. L’invention se rapporte à un programme informatique comportant des instructions pour la mise en œuvre des procédés de synchronisation ou de traitement de données tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur. Enfin l’invention se rapport à un support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l’exécution du procédé de synchronisation et/ou du procédé de traitement de données décrits précédemment. D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : FIG. 1 illustre un système de conférence comprenant un pont de conférence et une pluralité de dispositifs clients, au moins deux d’entre eux étant regroupés dans un espace commun et mettant en œuvre un procédé de synchronisation selon un mode de réalisation de l’invention, un des dispositifs client jouant également le rôle d’un dispositif serveur mettant en œuvre un procédé de traitement de données selon un mode de réalisation de l’invention ; FIG. 1 illustre un système de conférence comprenant un pont de conférence et une pluralité de dispositifs clients, au moins deux d’entre eux étant regroupés dans un espace commun et mettant en œuvre un procédé de synchronisation selon un mode de réalisation de l’invention, un dispositif serveur étant également regroupé dans l’espace commun et mettant en œuvre un procédé de traitement de données selon un mode de réalisation de l’invention ; FIG. 2 illustre sous forme d’organigramme les étapes principales d’un procédé de synchronisation mis en œuvre dans un dispositif client et un procédé de traitement de données mis en œuvre dans un dispositif serveur, selon un mode de réalisation de l’invention ; FIG. 3 illustre l’étape d’échange d’informations d’horodatage entre un dispositif client et un dispositif serveur mis en œuvre dans le procédé de synchronisation et le procédé de traitement de données selon l’invention ; FIG. 4 illustre une représentation des données enregistrées dans une mémoire temporaire du dispositif serveur lors d’un procédé de traitement de données selon l’invention ; et FIG. 5 illustre des exemples de réalisation structurelle d’un dispositif client ou d’un dispositif serveur selon un mode de réalisation de l’invention. La FIG. 1 décrit un système de conférence selon un mode de réalisation de l’invention. Ce système de conférence comprend un pont de conférence (PC) et une pluralité de dispositifs clients. Les dispositifs clients distants DD1 et DD2 sont des dispositifs distants représentés comme étant seuls dans leur espace respectifs E1, E2. Les dispositifs clients DC1 et DC2 sont représentés comme appartenant à un même espace commun (SR) comme une salle de réunion. Ces dispositifs DC1 et DC2 appartiennent à deux participants représentés en U1 et U2 qui sont donc présents dans cet espace commun. Bien évidemment, une telle conférence peut être prévue entre des participants de plusieurs espaces communs regroupant chacun plusieurs participants. Dans ce cas, dans chaque espace commun, les procédés selon l’invention décrits ci-après sont mis en œuvre. Chacun des dispositifs clients (DD1, DD2, DC1 et DC2) comporte au moins un microphone (Mi) et au moins un haut-parleur (HP) pilotés par une carte son interne (ISC pour « Internal sound card » en anglais) qui se charge de capter les sons de l’espace commun par le microphone et de restituer les sons des distants sur le haut-parleur. Les dispositifs peuvent également comporter un module logiciel client de conférence (CC ou PCC) pilotant une application de conférence de type par exemple application web de visioconférence. Les dispositifs clients distants DD1 et DD2 fonctionnent de façon classique, c'est-à-dire que la carte son interne pilotant le micro et le haut-parleur est configurée comme paramètre audio d’entrée et de sortie dans l’application de conférence pilotée par le module logiciel client de conférence (CC). Ce client de conférence récupère les sons captés de la carte son ISC et les transmet au pont de conférence PC. A l’inverse, le client de conférence récupère les données audio du pont de conférence et les transmet à la carte son pour qu’elles soient restituées sur le haut-parleur. Dans une variante de réalisation, le système de conférence ne comporte pas de pont de conférence, les dispositifs clients de la conférence communiquant alors directement entre eux. Les flèches d’échanges de données représentées sur les figures 1a et 1b représentent, pour celles illustrées en traits pleins, les échanges de signaux audio à travers un réseau de communication, en traits mixtes, les échanges de données autres que l’audio à travers un réseau de communication, par exemple la vidéo et celles illustrées en traits pointillés, les transferts de signaux acoustiques à travers l’espace commun. Dans l’espace commun SR illustré à la FIG. 1 , deux dispositifs clients sont représentés. Bien évidemment cet espace commun peut comprendre plus de deux dispositifs clients. A la FIG. 1 , un dispositif client DC1 est considéré comme un dispositif client principal car c’est cet appareil qui héberge le client de conférence responsable de la communication audio avec le pont de conférence ou avec les dispositifs distants pour les participants distants de l’espace commun. C’est également cet appareil qui héberge le dispositif, qu’on appellera par la suite le dispositif serveur, destiné à échanger les données audio avec le client de conférence. Ce dispositif a une fonction particulière par rapport à un autre dispositif client de cet espace commun. En effet, ce dispositif serveur comporte un module audio encore appelé module audio serveur (AS) qui met en œuvre un procédé de traitement selon un mode de réalisation de l’invention et tel que décrit ultérieurement en FIG. 2 . Pour ce dispositif serveur, une carte son virtuelle (VSC) est configurée comme paramètres audio d’entrée et de sortie de l’application de conférence pilotée par le module client de conférence principal (PCC). Cette carte son virtuelle est un module logiciel qui permet de router les signaux audio d’une application à une autre au sein d’un même dispositif. Dans le cas présent, la carte son virtuelle reçoit les données audio traitées en provenance du module audio serveur et les transmet au module client de conférence principal (PCC) pour un envoi vers le pont de conférence (PC). Selon un autre mode de réalisation, le dispositif serveur peut mettre à disposition du client de conférence le flux audio mixé via l'utilisation d'un espace de mémoire partagé, comme, par exemple un 'pipe' Linux, ou encore une communication IP. Il est à noter qu'un tel mode de réalisation nécessite que le client de conférence propose une interface de programmation spécifique, adaptée au dispositif serveur. Le module audio serveur (AS) reçoit les données audio de son propre module audio client (AC) qui récupère les données captées par le microphone via la carte son interne (ISC). Ce module audio serveur du dispositif serveur DC1 récupère également les données audio synchronisées des différents modules audio clients des dispositifs clients de l’espace commun, dans l’illustration de la FIG. 1 , le dispositif client DC2. Les données audio ont été obtenues selon un procédé de synchronisation décrit en référence à la FIG. 2 et mis en œuvre par les différents modules audio clients des dispositifs clients de l’espace commun. Ces données audio synchronisées sont sous la forme de paquets de données rééchantillonnés à la fréquence d’horloge du dispositif serveur, avec une information d’horodatage (« timestamp » en anglais) des paquets, l’information d’horodatage des paquets étant adaptée à l’horloge du dispositif serveur. Lors de la réception de ces paquets de données audio, le module audio serveur du dispositif serveur mémorise ces paquets dans une mémoire provisoire avec l’information d’horodatage associée. Il met en œuvre une étape d’alignement temporel des paquets reçus selon les informations d’horodatage associées pour obtenir un flux audio mixé qu’il envoie au module client de conférence principal via la carte son virtuelle. Les données ainsi traitées sont alors transmises au pont de conférence PC qui transmet les données audio aux autres dispositifs clients distants DD1 et DD2. Dans ce mode de réalisation, ce dispositif serveur est un dispositif tel qu’un terminal de communication ou un ordinateur d’un participant. Dans ce cas, le dispositif serveur est aussi un dispositif client. Dans un mode de réalisation, le dispositif client DC2 illustré à la FIG. 1 comporte en plus de sa carte son interne (ISC), et d’un module client de conférence (CC) tel que décrit précédemment, une carte son virtuelle (VSC) qui est configurée comme paramètres audio d’entrée et/ou de sortie de l’application de conférence pilotée par le module client de conférence (CC). En effet, lors de la configuration des paramètres audio d’entrée et de sortie de l’application de conférence du dispositif client, plusieurs choix sont possibles comme indiqué par le connecteur illustré, le choix ici étant entre la carte son interne (ISC) et la carte son virtuelle (VSC). Contrairement au dispositif serveur, cette carte son virtuelle ne reçoit pas de données audio d’un module audio si bien que le module client de conférence ne transmet pas de données audio au pont de conférence. De même si le module client de conférence reçoit des données audio du pont de conférence, il les transmet à la carte son virtuelle qui est configurée comme paramètre audio de sortie mais cette carte son virtuelle n’étant pas connectée au module audio client (AC), les données ne seront pas jouées par le haut-parleur. Ce mode de réalisation permet d’être compatible avec toute sorte d’application de conférence existant dans le commerce. Dans un autre mode de réalisation, l’application de conférence peut prévoir un mode de configuration dans lequel les sorties et entrées audio sont déconnectées. Dans un autre mode de réalisation, l’application de conférence peut prévoir un mode de configuration dans lequel la sortie audio est connectée à la carte-son interne pour émettre directement sur le haut-parleur, l’entrée audio est connectée à la carte-son virtuelle pour être alimentée par le module audio serveur, alimenté lui-même par les dispositifs clients. Dans un autre mode de réalisation, l’application de conférence peut prévoir un mode de configuration dans lequel l’entrée audio est connectée à la carte-son interne pour acquérir directement le signal du micro interne, et la sortie audio est connectée à la carte-son virtuelle pour alimenter l’audio serveur, qui alimentera lui-même les dispositifs clients. Dans un autre mode de réalisation, le dispositif client DC2 peut ne pas comporter de module client de conférence, ni de carte son virtuelle. Dans ce cas, l’utilisateur de ce dispositif client n’est pas connecté à une application de conférence mais participe à la conférence via le microphone de son dispositif et un module audio client (AC). Le dispositif client DC2 comporte un module logiciel audio client (AC) qui récupère les données captées par le microphone via la carte son interne (ISC) et en retour envoie les données reçues du module audio serveur vers le haut-parleur, via la carte son interne. Ce module audio client (AC) met en œuvre un procédé de synchronisation tel que décrit en référence à la FIG. 2 . Les données résultantes sont ensuite transmises au module audio serveur (AS) du dispositif serveur (DC1) via un réseau de communication, par exemple un réseau local. Ce réseau local peut être par exemple un réseau sans fil de type Wi-Fi ou Bluetooth ou bien un réseau filaire de type Ethernet. Ce module audio serveur (AS) tel que décrit précédemment, met en œuvre un procédé de traitement de données tel que décrit en référence à la FIG. 2 . Lorsque le dispositif serveur reçoit un flux audio du pont de conférence PC via son module client de conférence principal (PCC), il transmet ce flux aux dispositifs clients de son espace commun via sa carte son virtuelle et son module audio serveur. Les modules audio clients des dispositifs clients mettent en œuvre le procédé de synchronisation avant d’envoyer les données audio résultantes à leur carte son interne respective pour que ces données soient jouées sur leur haut-parleur respectif. Ainsi, les données sont jouées de façon synchronisée sur les dispositifs clients de l’espace commun, au plus près de l’utilisateur du dispositif. Ainsi, les micros et haut-parleurs des dispositifs clients de l’espace commun sont utilisés pour capter et restituer le son, au plus près de l’utilisateur du dispositif. Le son capté est ainsi plus intelligible que s’il avait été capté par un dispositif plus éloigné de l’utilisateur. Pour autant ce son capté n’est pas transmis directement par le dispositif client mais il est transmis, après horodatage adapté à l’horloge serveur par le dispositif client, au dispositif serveur qui se charge d’aligner temporellement et de mixer les données audio qu’il reçoit et qui sont ainsi synchronisées. La charge de traitement du dispositif serveur est réduite puisqu’il n’a pas à effectuer de traitement de synchronisation spécifique, tel qu’une analyse de corrélation entre signaux audio par exemple. De même, dans le mode de réalisation décrit ici, le dispositif audio serveur n’a pas non plus à effectuer le traitement de rééchantillonnage qui garantit une synchronisation fine au cours du temps, ce traitement étant pris en charge par le dispositif client. Les participants distants, utilisateurs des dispositifs DD1 et DD2, entendront donc plus distinctement les participants U1 et U2 tout en évitant qu’un phénomène d’écho ne les perturbe. Il est à noter que tous les flux audio mentionnés peuvent être mono, mais également stéréo ou multicanal. La FIG. 1 représente une variante de réalisation où un dispositif (DD) indépendant des dispositifs clients des participants est dédié pour mettre en œuvre le procédé de traitement de données tel que décrit en référence à la FIG. 2 . Ce procédé de traitement de données est mis en œuvre par un module audio serveur (AS) du dispositif de traitement dédié (DD). Ce module audio serveur, tel que décrit précédemment, récupère les données audio synchronisées des différents modules audio clients des dispositifs clients de l’espace commun. Dans un mode de réalisation, ce dispositif peut être par exemple un terminal, un ordinateur ou une pieuvre, présent dans la salle de réunion. Ce dispositif dédié peut comporter également une carte son (ISC) pilotant au moins un microphone et un haut-parleur et un module audio client (AC) qui récupère les données captées par le microphone via sa carte son interne (ISC) et en retour, envoie les données reçues vers le haut-parleur via sa carte son interne. Ce dispositif dédié agit comme un dispositif serveur, dans le sens où il reçoit les données audio synchronisées des autres dispositifs clients de l’espace commun, sous la forme de paquets de données rééchantillonnés à la fréquence d’horloge de ce dispositif serveur, avec une information d’horodatage des paquets de données, l’information d’horodatage étant adaptée à l’horloge du dispositif serveur. Lors de la réception de ces paquets de données audio, le module audio serveur (AS) de ce dispositif dédié, mémorise ces paquets dans une mémoire provisoire avec l’information d’horodatage associée. Il met en œuvre une étape d’alignement temporel des paquets reçus selon les informations d’horodatage associées pour obtenir un flux audio mixé qu’il envoie au module client de conférence principal qui se trouve sur un dispositif client principal, représenté ici en DC1. Cet envoi s’effectue via un bus de communication tel que par exemple une carte son externe (ESC) de ce dispositif client. Cela s’effectue par exemple par un branchement filaire entre les deux équipements, par exemple un branchement via une prise de type USB. Pour ce dispositif client principal, la configuration des données audio d’entrée et de sortie s’effectue par le choix de cette carte son externe au lieu de choisir sa carte son interne (ISC). Dans un exemple de réalisation, le dispositif serveur (DD) peut servir comme point d’accès de réseau sans fil (par exemple WiFi) pour que les dispositifs clients de l’espace commun puissent communiquer entre eux. La FIG. 2 illustre les étapes principales d’un procédé de synchronisation mis en œuvre dans un dispositif client (DC) tel que représenté en DC2 à la FIG. 1 et d’un procédé de traitement de données mis en œuvre dans un dispositif serveur (DS) tel que représenté en DC1 dans la FIG. 1 , selon un mode de réalisation de l’invention. De façon optionnelle, les dispositifs clients peuvent activer, dans une étape préalable E21, une application de conférence, pour participer à une conférence entre plusieurs participants, comme une visioconférence ou une conférence audio. Le dispositif serveur (DS) met en œuvre une étape préalable d’activation d’une application de conférence en E27. Pour cela, de façon classique, l’application logicielle installée sur le dispositif est ouverte. Une configuration des entrées et sorties audio à appliquer pour cette conférence est alors effectuée en E22, dans le cas où l’application de conférence a été activée pour le dispositif client et en E28 pour le dispositif serveur. Cette configuration s’effectue sur l’interface de l’application de conférence, par exemple, par l’utilisateur de la conférence audio. Pour le dispositif client, la configuration des paramètres audio de l’application de conférence consiste à déconnecter une carte son interne pilotant au moins le microphone du dispositif client. Dans un mode de réalisation, cette déconnection s’effectue en configurant une carte son virtuelle, à la place de la carte son interne, cette carte son virtuelle ne recevant aucune donnée audio, pour ce dispositif client. Dans un autre mode de réalisation où l’application de conférence propose comme configuration d’entrée/sortie un mode « néant », c’est à dire sans données audio d’entrée et de sortie, alors ce mode pourra être sélectionné. Il est également possible de configurer différemment l’entrée et la sortie audio de l’application et de n’appliquer par exemple que la configuration décrite précédemment qu’aux données d’entrée. Pour le dispositif serveur, la configuration des paramètres audio de l’application de conférence est effectuée pour que les données audio d’entrée de l’application proviennent d’un module de traitement produisant le flux audio mixé. Dans un mode de réalisation, cette configuration peut se faire en connectant au module de conférence pilotant l’application de conférence, une carte son virtuelle à la place de la carte son interne du dispositif serveur. Cette carte son virtuelle reçoit, pour ce dispositif serveur, les données audio traitées en E30 détaillée ci-après, avant l’envoi au pont de conf ou aux dispositifs distants directement, en E34 via le module client de conférence. De même, il est possible de configurer différemment l’entrée et la sortie audio de l’application et de n’appliquer par exemple que la configuration décrite précédemment qu’aux données d’entrée. Dans une variante de réalisation, le dispositif serveur peut mettre à disposition du client de conférence le flux audio mixé via l'utilisation d'un espace de mémoire partagé. Dans ce cas, le client de conférence propose une interface de programmation spécifique, adaptée au dispositif serveur pour qu’une telle configuration des données entrées et sorties soit possible. Les étapes E23 et E29 représentent les échanges d’informations d’horodatage entre un dispositif client et un dispositif serveur de l’espace commun. Cet échange d’informations permet au dispositif client de connaitre à la fois le décalage d’horloge et une dérive d’horloge qui peut exister entre le dispositif client et le dispositif serveur. La FIG. 3 illustre cette étape d’échange d’informations d’horodatage entre les dispositifs clients et le dispositif serveur d’un espace commun. Ces échanges peuvent s’effectuer par exemple selon le protocole NTP (Pour « Network Time Protocol » en anglais) tel que décrit par exemple dans la spécification technique RFC-5905 « Network Time Protocol Version4 » de Juin 2010. D’autre protocoles de synchronisation réseau peuvent bien sûr être utilisés ici comme par exemple, le protocole PTP (pour « Precision Time Protocol » en anglais). Dans un premier temps à l’instant T C S , le dispositif client émet un message M, sous la forme d’un paquet de données, qu’on peut appeler données de synchronisation, pour interroger le dispositif serveur sur l'heure courante, il envoie ce message dans lequel il renseigne un premier champ avec l'heure courante T C S indiquée par son horloge locale ; A T M R , lorsque le dispositif serveur reçoit le message M, il complète aussitôt un deuxième champ du message M avec l'heure courante T M R indiquée par son horloge locale ; A T M S , lorsque le dispositif serveur émet son message de réponse, il complète un troisième champ avec l'heure courante T M S indiquée par son horloge locale ; A T C R , lorsque le dispositif client reçoit le message de réponse, il note aussitôt l'heure T C R de réception indiquée par son horloge locale. Le dispositif client peut alors calculer à l’étape E24 illustrée à la FIG. 2 , les délais aller/retour « delta » de ces deux messages qui permet d’évaluer la latence du réseau ainsi que l'écart « theta » entre son horloge locale et celle du dispositif serveur. On estime ici que le délai aller et le délai retour (delta) est le même, c'est-à-dire que les conditions réseau restent inchangées lors de cet échange de message. Le calcul effectué prend aussi en compte une dérive possible « alpha » de l’horloge du dispositif client par rapport à celle du dispositif serveur. En effet, deux appareils fonctionnants indépendamment possèdent leur propre horloge. Une horloge est définie comme une fonction monotone égale à un temps qui augmente au rythme déterminé par la fréquence d’horloge. Elle peut prendre son origine à l’instant où l’appareil est mis en route, ou à un instant arbitrairement défini comme, par exemple le 1 er janvier 1970 pour NTP. Les horloges de deux appareils sont forcément différentes et trois paramètres sont définis: - le décalage d’horloge (theta) : différence de temps à l’origine entre deux horloges ; - la dérive d’horloge (alpha) : rapport de fréquences entre deux horloges ; - la déviation d’horloge : variation de la dérive au cours du temps, ou dérivée seconde de l’horloge par rapport au temps. Une modélisation classique d’une horloge néglige la déviation d’horloge, principalement causée par construction du composant appelé quartz, mais aussi par des changements de température. Ainsi, dans un contexte réseau serveur/client, comme ici entre un dispositif serveur et un dispositif client, l’horloge du dispositif client Tc s’exprime en fonction de l’horloge du dispositif serveur T M suivant une équation telle que T C = f(T M ) = alpha *T M + theta où alpha représente la dérive d’horloge du client par rapport à celle du dispositif serveur, et theta représente le décalage de l’horloge du client. Ainsi, dans le cas présent, à l’étape E24 illustrée à la FIG. 2 , les équations suivantes sont utilisées pour estimer le délai delta : T C S + delta = alpha* T M R + theta T C R – delta = alpha* T M S + theta Ce qui donne la valeur de delta selon l’équation : delta = ((alpha* T M R – T C S ) + (T C R – alpha* T M S )) / 2 Cette valeur représentant le décalage entre les horloges du dispositif serveur et celle du dispositif client est un temps qui peut s’exprimer en secondes ou millisecondes. Cet échange d’informations d’horodatage (E23, E29) s’effectue par des étapes d’envoi réguliers d’un paquet de données (message M) et de collecte de données d’horodatage d’envoi et de réception de ce paquet. Dans un mode de réalisation, un paquet de données est envoyé toutes les secondes. Une autre fréquence d’envoi peut bien sûr être prévue. Les informations sont collectées sur une fenêtre temporelle glissante qui peut être par exemple d’une heure. Pour pouvoir obtenir la valeur de la dérive d’horloge « alpha », une régression linéaire (par exemple une fonction des moindres carrés) est effectuée en prenant en compte les valeurs d’horodatage T M S , T C R collectées dans cette fenêtre temporelle, c'est-à-dire les valeurs d’horodatage collectées lors des retours du paquet de données du dispositif serveur au dispositif client. On obtient ainsi une valeur de alpha représentant la dérive d’horloge, c'est-à-dire le rapport de fréquences entre l’horloge du dispositif serveur et l’horloge du dispositif client. Au démarrage d’une application audio client mettant en œuvre le procédé de synchronisation, la fenêtre temporelle est vide ou n’a pas atteint la taille prédéfinie. Dans ce cas, la valeur de la dérive est fixée à 1 et un délai minimum est respecté avant de calculer une nouvelle valeur de la dérive avec les données collectées dans cet intervalle de temps minimum. Cet intervalle peut être par exemple de 7s. Petit à petit, la taille de la fenêtre de l’historique des données collectées atteint une valeur prédéterminée, par exemple 30 min ou 1h. On ne garde alors que les données sur cette fenêtre glissante, les données antérieures sont effacées de la mémoire du dispositif. En effet, une modification de la configuration réseau pourrait par exemple mener à une modification des valeurs de délai ou de dérive. Dans un mode de réalisation particulier, une fonction de régression linaire est également appliquée aux données d’aller du paquet de données du dispositif client au dispositif serveur. Ainsi, si une grande différence de la valeur d’alpha est constatée avec ce nouveau calcul, on pourra soit filtrer la mesure problématique, soit encore appliquer une correction à la valeur d’alpha. Dans ce dernier cas, une moyenne entre les deux valeurs pourra par exemple être effectuée. Dans une variante de réalisation, la fonction de régression linaire est appliquée aléatoirement soit aux données de retour ou d’aller du paquet de données. Cette variante permet de s’affranchir des différences qui pourraient exister entre les données d’aller et les données de retour, par exemple des conditions réseau qui ne seraient pas identiques ou des conditions d’envoi et de réception qui seraient différentes. La valeur de la dérive obtenue est une valeur sans dimension égale au rapport des fréquences d’horloge du dispositif serveur et du dispositif client. Cette valeur est ensuite utilisée pour adapter, en E25, les données captées par le microphone via la carte son ISC du dispositif client avant de les transférer en E26 vers le dispositif serveur ou bien pour adapter les données reçues du dispositif serveur avant diffusion vers le haut-parleur du dispositif client via sa carte son ISC. Pour cela, en E25, les données captées par le microphone du dispositif client sont traitées par rééchantillonnage selon la valeur de la dérive d’horloge calculée. Connaissant la valeur de la fréquence d’horloge du dispositif serveur F M , pour chaque paquet audio, un module de rééchantillonnage est mis en œuvre pour adapter la fréquence d’échantillonnage (F C ) du dispositif client à celle du dispositif serveur de la façon suivante : F C = F M * alpha. L’instant T C capture de la capture d’un paquet de données audio par le dispositif client est converti en donnée d’horodatage adaptée à l’horloge du dispositif serveur en utilisant la fonction inverse de f défini ci-dessus, de la façon suivante : T M capture =f -1 (T C capture ), c'est-à-dire ici T M capture =( T C capture – theta)/alpha. On obtient ainsi des paquets de données rééchantillonnés à la fréquence de l’horloge du dispositif serveur F C avec des instants de capture adaptés à l’horloge du dispositif serveur. Ces paquets de données rééchantillonnés sont transmis au dispositif serveur avec une information d’horodatage de ce paquet selon l’horloge du dispositif serveur. De même, lors de la réception de données audio par le dispositif serveur qui les a lui-même reçu du pont de conférence, les paquets de données sont rééchantillonnés en E25 selon la valeur de la dérive d’horloge calculée et transmis au haut-parleur du dispositif client via sa carte son ISC, pour que les données audio soient jouées. Ainsi, la diffusion des flux audio sur les différents haut-parleurs des dispositifs clients d’une même salle de réunion, n’engendre pas de phénomène d’échos puisqu’il n’y a plus de décalage, ni de dérive dans le temps, des sons joués. La restitution s’effectue de plus, au plus près des utilisateurs de ces dispositifs clients pour une meilleure compréhension du flux audio. Si l'information de dérive d’horloge n'était pas partagée, il en résulterait inexorablement, au moment où le décalage d'horloge devrait être mis à jour du fait de la dérive temporelle, soit un recouvrement temporel, soit un silence, entre 2 paquets audio successifs issu d'un même client au moment d’aligner temporellement les paquets reçus. Si on n'utilisait pas le rééchantillonnage pour donner aux paquets audio la durée adéquate dans l'horloge du serveur, il en résulterait inexorablement soit une trop grande accumulation de données dans le serveur si la fréquence d'horloge du serveur est inférieure à celle du client, soit une famine de données dans le serveur si la fréquence d'horloge du serveur est supérieure à celle du client, aboutissant dans les 2 cas à des artefacts audio ("clics") audibles. Du côté du dispositif serveur, un procédé de traitement de données audio est mis en œuvre. De la même façon que décrit pour le dispositif client, un échange d’informations d’horodatage entre un dispositif client de l’espace commun et le dispositif serveur est effectué par les étapes E23 et E29 illustrées à la FIG. 2 . Comme décrit précédemment, le dispositif client transmet en E26 des paquets de données rééchantillonnés à la fréquence d’horloge du dispositif serveur, avec une information d’horodatage, l’information d’horodatage étant adaptée à l’horloge du dispositif serveur. Lors de la réception de ces paquets de données audio en E30, le dispositif serveur mémorise en E31 ces paquets dans une mémoire provisoire de type FIFO (pour First In First Out » en anglais) avec l’information d’horodatage associée. Puis en E32, une étape d’alignement temporel des paquets reçus est effectuée selon les informations d’horodatage associées. Une représentation de ces paquets de données alignés dans la mémoire temporaire de type FIFO est illustrée en FIG. 4 . Cette FIG. 4 montre que les paquets de données (illustrés par des blocs consécutifs AP) reçus des différents dispositifs clients (DC 1 , DC 2 , …, DC k ) sont enregistrés en mémoire avec l’information d’horodatage associée. Ainsi, les paquets de données reçues de DC 1 ont été mis en mémoire dans une mémoire FIFO dédiée à DC 1 avec les informations d’horodatage associées T 1,M i+n ,…, T 1,M i+3 ,T 1,M i+2 , T 1,M i+1 à T 1,M i . Il en est de même pour les paquets de données reçus des dispositifs clients DC 2 à DC K avec les informations d’horodatage correspondantes. Un alignement temporel selon l’étape E32 de la FIG. 2 permet de décaler les blocs de données pour qu’à un instant T, les informations d’horodatage des blocs enregistrés dans les différentes FIFO correspondent. Ce décalage est illustré à la FIG. 4 . L’ajustement temporel est effectué en alignant toutes les données des FIFO de sorte qu’un axe vertical corresponde au même instant T. A l’étape E33 de la FIG. 2 , le dispositif serveur mixe les différents paquets de données ainsi alignés à un instant T pour pouvoir constituer un flux audio mixé (Flux-T) à transmettre au pont de conférence en E34. L’étape de mixage peut être une simple sommation de tous les signaux alignés, ou une sommation avec une pondération arbitraire ou issue d’une analyse. Une analyse des variations de volume entre différents intervenants permet par exemple de définir un gain de compensation à appliquer comme pondération aux signaux de faible volume. Dans le cas où il n’existe pas de paquets de données à cet instant T pour un des dispositifs clients, alors une donnée de silence peut être insérée. Lors de la réception de flux audio en provenance du pont de conférence (PC) en E30, le dispositif serveur envoie les paquets audio aux dispositifs clients de l’espace commun en E26 pour que ceux-ci les traitent comme expliqués précédemment à l’étape E25. On a illustré sur la FIG. 5 , une réalisation structurelle d’un dispositif client ou d’un dispositif serveur (100) selon un mode de réalisation de l’invention. De tels dispositifs peuvent être inclus dans un terminal de communication de type smartphone, tablette électronique ou bien un ordinateur personnel, voire un dispositif dédié comme une pieuvre de conférence audio. Le dispositif client comporte un circuit de traitement incluant typiquement : - une mémoire MEM pour stocker des données d’instructions d’un programme informatique au sens de l’invention ainsi que différentes applications, une application de conférence audio ou visio pouvant, par exemple, faire partie de ces applications; - une interface INT apte à recevoir des instructions utilisateurs comme par exemple des informations de configuration de paramètres audio et à afficher différentes données, comme, par exemple des images vidéos d’une conférence de type visioconférence ; - une carte son ISC apte à récupérer les données audio captées par un microphone Mi et à envoyer des données audio à un haut-parleur HP pour leur restitution ; - un module logiciel audio client AC apte à récupérer les données captées par le microphone via la carte son interne ISC. Ce module audio client peut également envoyer les données reçues vers le haut-parleur via la carte son interne. Ce module audio client AC met en œuvre un procédé de synchronisation tel que décrit en référence à la FIG. 2 ; - une interface de communication COM apte à envoyer ou recevoir des données, notamment des données audio, à ou vers un autre dispositif, tel qu’un dispositif serveur via un réseau R ; - un processeur PROC pour exécuter les instructions de programme informatique que stocke la mémoire MEM, notamment les instructions pour la mise en œuvre du procédé de synchronisation tel que décrit en référence à la FIG. 2 ; le processeur étant apte à piloter les différents modules décrits. Le dispositif client peut comporter, de façon optionnelle, un module logiciel client de conférence CC apte à piloter une application de conférence de type par exemple application web de visioconférence. Il peut dans ce cas comporter une carte son virtuelle VSC configurée comme le module audio d’entrée et/ou de sortie de l’application de conférence pilotée par le module client de conférence CC. Cette carte son virtuelle est un module logiciel qui permet de router les signaux audio d’une application à une autre au sein du dispositif. Dans le cas d’un dispositif client, la carte son virtuelle ne reçoit aucune donnée audio. Elle peut être utilisée pour déconnecter du module client de conférence, la carte son ISC. De même, le dispositif serveur, dans un mode de réalisation, comporte un circuit de traitement incluant typiquement : - une mémoire MEM pour stocker des données d’instructions d’un programme informatique au sens de l’invention ainsi que différentes applications, une application de conférence audio ou visio pouvant, par exemple, faire partie de ces applications ; - une interface INT apte à recevoir des instructions utilisateurs comme par exemple des informations de configuration de paramètres audio et à afficher différentes données, par exemple les images vidéos d’une conférence de type visioconférence ; - une carte son ISC apte à récupérer les données audio captées par un microphone Mi et à les envoyer vers un module audio client AC et à l’inverse à recevoir des données audio du module audio client et à les envoyer à un haut-parleur HP pour leur restitution. - un module logiciel client de conférence CC, qui est aussi appelé dans le cas du dispositif serveur, client de conférence principal, apte à piloter une application de conférence de type, par exemple, application web de visioconférence et à envoyer des flux audio vers d’autres dispositifs distants ou à un pont de conférence via l’interface de communication COM. - un module logiciel audio client AC apte à récupérer les données captées par le microphone via la carte son interne ISC et envoyer les données reçues vers le haut-parleur via la carte son interne. - un module audio serveur AS qui met en œuvre un procédé de traitement selon un mode de réalisation de l’invention et tel que décrit en référence à la FIG. 2 . Le module audio serveur AS reçoit les données audio de son propre module audio client AC et récupère également les données audio synchronisées des différents modules audio clients des dispositifs clients d’un espace commun, via l’interface de communication COM pour mettre en œuvre le procédé de traitement. - une carte son virtuelle VSC configurée comme le module audio d’entrée et de sortie de l’application de conférence pilotée par le module client de conférence CC. Cette carte son virtuelle est un module logiciel qui permet de router les signaux audio d’une application à une autre au sein du dispositif. Dans le cas d’un dispositif serveur, la carte son virtuelle reçoit les données audio traitées en provenance du module audio serveur et les transmet au module client de conférence CC ; la carte son virtuelle peut également envoyer les données audio issues du module client de conférence CC vers le module audio serveur. - une interface de communication COM apte à envoyer ou recevoir des données, notamment des données audio, à ou vers d’autres dispositifs, tel que des dispositifs clients ou un pont de conférence via un réseau R ; - un processeur PROC pour exécuter les instructions de programme informatique que stocke la mémoire MEM, notamment les instructions pour la mise en œuvre du procédé de traitement de données tel que décrit en référence à la FIG. 2 ; le processeur étant apte à piloter les différents modules décrits ci-dessus. Dans un autre mode de réalisation, le dispositif serveur peut ne pas comporter de module logiciel client de conférence CC, ni de carte virtuelle VSC. Ce dispositif serveur peut posséder, en revanche, un port de branchement de type USB pour communiquer des données audios à un autre dispositif client. Ce type de dispositif serveur est par exemple un dispositif dédié pour les conférences audio, comme, par exemple une pieuvre de conférence audio. Bien entendu, cette FIG. 5 illustre un exemple d’une réalisation structurelle d’un dispositif (client ou serveur) au sens de l’invention. Les figures 1 à 4 commentées ci-dessus décrivent en détails des réalisations fonctionnelles de ces dispositifs. Procédé de synchronisation de données audio lors d’une conférence audio entre une pluralité de participants via des dispositifs clients, le procédé étant mis en œuvre par un premier dispositif client de la conférence partageant un même espace commun qu’un second dispositif client et dans lequel les étapes suivantes sont exécutées : - échange d’informations d’horodatage (E23, E29) entre le dispositif client et un dispositif serveur connecté avec les dispositifs clients de l’espace commun ; - calcul (E24) d’une dérive d’horloge du dispositif client par rapport au dispositif serveur à partir des informations échangées ; - lors de la capture de données audio via un microphone du dispositif client, traitement (E25) des paquets audio capturés par rééchantillonnage des paquets selon la valeur de la dérive d’horloge calculée et transmission (E26) des paquets rééchantillonnés au dispositif serveur avec une information d’horodatage des paquets. Procédé selon la revendication 1, comportant en outre les étapes préalables suivantes : - activation d’une application de conférence (E21) ; - configuration (E22) des paramètres audio de l’application de conférence pour déconnecter une carte son interne pilotant au moins le microphone du dispositif client. Procédé selon l’une des revendications 1 ou 2, dans lequel lors de la réception de données audio du dispositif serveur, le procédé met en œuvre une étape de conversion des données reçues par rééchantillonnage selon la valeur de la dérive d’horloge calculée et une étape de transmission des paquets rééchantillonnés à au moins un haut-parleur du dispositif client. Procédé selon l’une des revendications 1 ou 2, dans lequel l’échange d’informations d’horodatage s’effectue par des étapes d’envoi réguliers d’un paquet de données et de collecte de données d’heure d’envoi et de réception du paquet de données, sur une fenêtre temporelle. Procédé selon la revendication 4, dans lequel le calcul de la dérive d’horloge entre le dispositif client et le dispositif serveur est effectué à partir des données d’heure collectées sur une fenêtre temporelle glissante et selon une fonction de régression linéaire appliquée aux données d’horodatage collectées lors des retours du paquet de données du dispositif serveur au dispositif client. Procédé selon la revendication 5, dans lequel une fonction de régression linaire est également appliquée aux données d’horodatage collectées lors des allers du paquet de données du dispositif client au dispositif serveur. Procédé selon la revendication 5, dans lequel la fonction de régression linaire est appliquée aléatoirement soit aux données d’horodatage collectées lors des retours ou bien des allers du paquet de données. Procédé selon l’une des revendications précédentes, dans lequel l’information d’horodatage des paquets audio rééchantillonnés est adaptée à l’horloge du dispositif serveur avant d’être envoyée au dispositif serveur. Procédé de traitement de données audio lors d’une conférence audio entre une pluralité de participants via des dispositifs clients, le procédé étant mis en œuvre par un dispositif serveur connecté avec au moins un dispositif client partageant un même espace commun et dans lequel les étapes suivantes sont exécutées : - échange (E23, E29) d’informations d’horodatage entre un dispositif client de l’espace commun et le dispositif serveur ; - lors de la réception (E30) de paquets de données audio avec des informations d’horodatage associées, en provenance des dispositifs clients de l’espace commun : - mémorisation (E31) des paquets dans une mémoire provisoire ; - alignement (E32) temporel des paquets mémorisés, en fonction des informations d’horodatage; - mixage (E33) des paquets alignés pour obtenir un flux audio mixé ; - envoi (E34) du flux audio mixé à destination de participants distants de la conférence audio. Procédé selon la revendication 9, comportant en outre les étapes préalables suivantes : - activation d’une application de conférence (E27) ; - configuration (E28) des paramètres audio de l’application de conférence pour que les données audio d’entrée de l’application proviennent d’un module de traitement produisant le flux audio mixé. Dispositif client partageant un même espace commun qu’un second dispositif client lors d’une conférence audio entre une pluralité de participants, le dispositif client comportant au moins un microphone (Mi) piloté par une carte son interne, et au moins un module audio client (AC) piloté par un microprocesseur et apte à mettre en œuvre un procédé de synchronisation de données audio, le procédé comportant les étapes suivantes: - échange d’informations d’horodatage entre le dispositif client et un dispositif serveur connecté avec les dispositifs clients de l’espace commun ; - calcul d’une dérive d’horloge du dispositif client par rapport au dispositif serveur à partir des informations échangées ; - lors de la capture de données audio via le au moins un microphone du dispositif client, traitement des paquets audio capturés par rééchantillonnage des paquets selon la valeur de la dérive d’horloge calculée et transmission des paquets rééchantillonnés au dispositif serveur avec une information d’horodatage des paquets. Dispositif client selon la revendication 11, comportant en outre un module client de conférence (CC) apte à activer une application de conférence, la carte son interne étant configurée comme étant déconnectée du module client de conférence pour l’application de conférence. Dispositif serveur connecté avec au moins un dispositif client partageant un même espace commun lors d’une conférence audio entre une pluralité de participants, le dispositif serveur comportant au moins un module audio serveur (AS) piloté par un microprocesseur et apte à mettre en œuvre un procédé de traitement de données audio, le procédé comportant les étapes suivantes: - échange d’informations d’horodatage entre un dispositif client de l’espace commun et le dispositif serveur ; - lors de la réception de paquets de données audio avec des informations d’horodatage associées, en provenance des dispositifs clients de l’espace commun : - mémorisation des paquets dans une mémoire provisoire ; - alignement temporel des paquets mémorisés, en fonction des informations d’horodatage ; - mixage des paquets alignés pour obtenir un flux audio mixé ; - envoi du flux audio mixé à destination de participants distants de la conférence audio. Dispositif serveur selon la revendication 13, comportant un module client de conférence (CC) apte à activer une application de conférence et au moins une carte son virtuelle configurée comme entrée des données audio du module client de conférence de la conférence audio, la carte son virtuelle recevant le flux audio mixé du module audio serveur. Terminal de communication comprenant un dispositif client selon l’une des revendications 11 à 12 et/ou un dispositif serveur selon l’une des revendications 13 à 14. Support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l’exécution du procédé de synchronisation selon l’une des revendications 1 à 8 et/ou du procédé de traitement de données selon l’une des revendications 9 à 10.