Brevet FR3054399A1 — publié le 20180126

PILOTAGE DE DISPOSITIFS MULTIMEDIA BLUETOOTH La description a notamment pour objet un dispositif de pilotage de dispositifs multimédia Bluetooth, en particulier d'enceintes Bluetooth (Bluetooth est une marque déposée de Bluetooth SIG, Inc). Bluetooth est un standard de communication bien connu de l'homme du métier, défini depuis 1994 et géré par un groupe d'industriels (le Bluetooth SIG) qui en édite des versions successives. La version actuelle est la version 4.2 et une version 5 vient d'être annoncée. Bluetooth permet un échange bidirectionnel de données à courte distance (on parle de réseau piconet, ce qui désigne un réseau couvrant une zone personnelle). La portée d'un équipement Bluetooth est ainsi limitée à quelques dizaines de mètres. Bluetooth utilise des ondes radio qui se situent dans la bande UHF (entre 300 MHz et 3 GHz). Bluetooth vise à simplifier les connexions entre les appareils électroniques en supprimant des liaisons filaires. Bluetooth permet ainsi remplacer par des communications sans fil les câbles entre un dispositif multimédia maître (chaîne Hi-fi, autoradio, ordinateur, tablette, téléphone mobile, etc.) et des dispositifs multimédia cibles tels que des enceintes agencées pour restituer un flux multimédia reçu. Les enceintes Bluetooth rencontrent un certain succès du fait de leur grande portabilité. Cependant, le standard Bluetooth ne permet pas à une puce Bluetooth de transmettre plusieurs flux audio en parallèle à plusieurs dispositifs multimédia que l'on souhaite synchroniser, si un profil d'échange de données audio dit profil A2DP est utilisé. Ce profil A2DP ne permet pas d'effectuer une transmission point à multipoints synchronisée. Le standard Bluetooth indique en effet: "The following restrictions are applied to this profile: 1. The profile does not support a synchronized point-to-multipoint distribution." (soit en français: "les restrictions suivantes s'appliquent à ce profil : 1. ce profil ne supporte pas une distribution point à multipoints 3054399 2 synchronisée"). Ainsi, il n'est pas possible en théorie de concevoir un dispositif de pilotage synchronisé de dispositifs multimédia Bluetooth, le dispositif de pilotage synchronisé comprenant une seule puce Bluetooth pour piloter plusieurs dispositifs multimédia, car Bluetooth ne le permet pas. 5 Il a déjà été proposé de créer un dispositif Bluetooth point à multipoints à destination de plusieurs enceintes. Par exemple, la demande FR2920930, déposée le 6 septembre 2007 et désormais définitivement déchue, proposait un tel dispositif. Mais cette demande ne décrivait pas comment réaliser un tel dispositif, qui paraît impossible au regard du standard 10 Bluetooth si l'on n'utilise qu'une puce Bluetooth. L'insuffisance de description de cette demande empêche d'en retirer un enseignement pertinent quant à la manière de réaliser une liaison point à multipoints, et a fortiori une liaison point à multipoints synchronisée. Bien que Bluetooth ne le prévoie pas, il serait possible de créer dans une 15 puce Bluetooth de dispositif de pilotage plusieurs SEPS Source afin de piloter plusieurs dispositifs Bluetooth (au lieu de prévoir dans un circuit de pilotage autant de puces Bluetooth qu'il y a de dispositifs Bluetooth à piloter). Un SEP est un "Stream End Point" (en français, point d'extrémité de flux). Les communications Bluetooth s'effectuent en point à point entre deux 20 SEPS. Un SEP représente les ressources et les capacités d'un dispositif. Par exemple, un dispositif tel qu'un téléphone portable peut disposer de trois SEPS, l'un représentant ses capacités en tant que récepteur vidéo, un autre représentant ses capacités en tant que récepteur audio avec un codec SBC et un dernier représentant ses capacités de récepteur audio avec un 25 codec aptX. Chaque codec doit être associé à un SEP différent de celui ou ceux au(x)quel(s) est(sont) associé(s) un(des) autre(s) codec(s), mais un même codec peut être associé à plusieurs SEPs. Cependant, dans le cas où les dispositifs Bluetooth sont des dispositifs multimédia Bluetooth, se pose le problème de synchroniser les signaux 30 transmis à chacun de ces dispositifs multimédia Bluetooth en A2DP. L'acronyme A2DP signifie "Advanced Audio Distribution Profile", soit en français profil de distribution audio avancé. Le profil A2DP conventionnel 3054399 3 définit un ensemble de protocoles et procédures pour l'échange de données audio au travers du protocole Bluetooth entre un dispositif maître (dit Source) et un dispositif esclave (dit "Sink", terme signifiant "puits" en français et désignant la destination ultime d'un flux, par exemple une 5 enceinte Bluetooth). Ce profil A2DP est construit à partir de plusieurs briques définies par le standard Bluetooth. Le profil s'appuie notamment sur des briques bas niveau bien connues de l'homme du métier. Ces briques comprennent: - une brique "Baseband" (mot anglais signifiant "bande de base" en 10 français, la brique Baseband étant identifiée par la référence BB sur la figure 1), - une brique "LMP" (acronyme de l'anglais "Link Manager Protocol" signifiant protocole de gestion de lien), - une brique "L2CAP" (acronyme de l'expression "Logical Link Control 15 and Adaptation Protocol" signifiant protocole de contrôle et d'adaptation de lien logique), - une brique "SDP" ("Service Discovery Protocol", soit en français: protocole de découverte de service). Ces briques sont des protocoles définis dans le standard Bluetooth. 20 Le profil A2DP s'appuie également sur une couche haut niveau dite couche applicative (références AASo et AASi sur la figure 1, respectivement pour "Application Audio Source" et "Application Audio Sink", signifiant respectivement source audio applicative et destination audio applicative). Il s'agit de la couche dans laquelle le dispositif détermine les paramètres de 25 transport et les différents services disponibles. C'est aussi à ce niveau qu'est effectué le choix du codec utilisé pour transmettre les données audio (ce qui peut impliquer un décodage suivi d'un ré-encodage, lorsque le flux audio à transmettre est déjà encodé, ce qui est habituellement le cas). Le profil A2DP s'appuie enfin sur une brique AVDTP (acronyme signifiant 30 "Audio/Video Distribution Transport Protocol" soit: protocole de transport de 3054399 4 distribution audio/vidéo) qui définit les transactions binaires entre des dispositifs Bluetooth pour la mise en place d'un flux et pour la diffusion d'un flux audio et/ou vidéo utilisant L2CAP. Ceci recouvre donc des procédures d'établissement du flux audio, de négociation des paramètres du flux audio 5 et de transmission des données du flux audio. AVDTP comprend une entité de signalisation pour la négociation de paramètres de diffusion et une entité de transport pour gérer le flux lui-même. L'AVDTP définit un protocole de transport des données audio et/ou vidéo. Plus précisément, l'AVDTP s'intéresse au transport de données audio et/ou vidéo entre deux SE Ps. 10 Une limitation imposée par l'AVDTP selon le standard Bluetooth est que lorsque qu'une connexion a été négociée entre deux SEPs, ces deux derniers doivent être verrouillés l'un à l'autre pour la diffusion du flux. Par défaut un SEP connecté refuse toute nouvelle connexion. Sur des produits Bluetooth récents, une fonction dite "social mode" (mode social en français) 15 permet parfois de changer ce comportement par défaut. Mais cette fonction "social mode" qui permet une nouvelle connexion interrompt la connexion en cours. On peut donc être en présence par exemple de deux téléphones connectés à une même enceinte Bluetooth. Mais on ne peut mettre en place plusieurs transports simultanés. Le basculement vers une nouvelle 20 connexion se fait typiquement par terminaison de la connexion précédente tout en gardant le téléphone précédemment connecté en mémoire. En conséquence, si l'on n'a qu'un seul et unique SEP audio source sur un dispositif Source alors un seul transport AVDTP peut être établi vers un dispositif Sink donné à un instant donné, d'après le standard Bluetooth. 25 La couche L2CAP définit le protocole minimal d'échange de données de la spécification Bluetooth. La couche L2CAP permet notamment la segmentation et le réassemblage des paquets, le multiplexage et la qualité de service. C'est à partir de cette couche L2CAP que sont réalisés les différents protocoles de transport (comme l'AVDTP) à la base des différents 30 profils Bluetooth (comme l'A2DP). Un canal L2CAP est créé entre un CID ("Channel Identifier", signifiant identifiant de canal en français) d'un dispositif maître et un CID d'un dispositif esclave, permettant l'échange de données entre ces deux dispositifs. Les canaux L2CAP font chacun l'objet 3054399 5 d'un paramétrage permettant notamment de gérer le contrôle des flux de données transitant dans des canaux que L2CAP définit (canaux L2CAP). Pour cela, différents paramètres peuvent être pris en compte indépendamment pour chaque canal L2CAP, notamment: 5 - Un paramètre FTO ou "Flush Timeout" (expression anglaise signifiant: délai d'expiration pour la suppression) définit un délai de péremption d'un paquet de données dans une mémoire tampon d'un dispositif maître. Ce délai est infini par défaut (mode bloquant), ce qui signifie qu'un paquet transmis qui n'arrive pas à destination est renvoyé tant 10 qu'aucun paquet (le paquet initial ou les paquets renvoyés) n'est pas parvenu à destination. Mais le délai peut aussi être tel qu'il n'y ait jamais de retransmission (si le paramètre "Flush Timeout" est fixé à une valeur appropriée définie par le standard Bluetooth), ce qui revient en quelque sorte à un délai nul. Le délai peut également prendre une valeur finie. Il 15 existe par ailleurs une variable booléenne appelée en anglais "flag non- automatically flushable" (signifiant en français: drapeau pas de suppression automatique) présente dans les paquets Bluetooth, permettant d'indiquer que le paquet concerné ne peut pas être supprimé automatiquement. - Un paramètre QoS (acronyme de l'expression anglaise "Quality of 20 service" signifiant qualité de service) permettant de définir notamment la latence maximale entre la prise en compte d'un paquet à transmettre dans un canal L2CAP et sa transmission effective. - Des paramètres appelés "Extended Flow features" (signifiant caractéristiques de flux étendues en anglais), remplaçant et complétant la 25 combinaison des paramètres "Flush Timeout" et "QOS" précités. Ces paramètres sont négociés entre la pile Bluetooth d'un dispositif Bluetooth maître et la pile Bluetooth d'un dispositif Bluetooth esclave et, en dehors des valeurs par défaut, ne sont pas toujours supportés. L2CAP permet la mise en oeuvre de différents modes. Ces modes sont 30 également des paramètres des canaux L2CAP, au même titre que les paramètres "Extended Flow features" ou que le paramètre "Flush Timeout". 3054399 6 C'est l'ensemble de ces paramètres (modes compris) qui permet de modifier le contrôle des flux. Chaque mode définit des procédures différentes de gestion des flux de données. Dans le cadre du Bluetooth classique (dit BR/EDR) cinq modes opératoires sont possibles pour un 5 canal L2CAP. Ces modes sont: - "Basic Mode" (signifiant mode basique L2CAP en français), - "Flow Control Mode" (signifiant mode contrôle de flux en français), - "Retransmission Mode" (signifiant mode retransmission en français), - "Enhanced Retransmission Mode" (dit "ERTM", et signifiant mode 10 retransmission accrue en français) et - "Streaming Mode" (dit "SM", et signifiant mode de diffusion en français). Le "Basic Mode" est le mode par défaut et est supporté par toutes les piles Bluetooth. Il ne requiert aucun paramétrage. Le "Flow Control Mode" 15 envoie des paquets mais n'effectue jamais aucune retransmission des paquets perdus. Cependant, ces paquets (appelés PDUs) sont détectés lorsqu'ils sont perdus, et le "Flow Control Mode" permet la communication d'un compte rendu listant les paquets perdus. Le "Flow Control Mode" et le "Retransmission Mode" ne peuvent être utilisés que si l'"ERTM" et le "SM" 20 ne sont pas utilisables. Ces deux modes ("Flow Control Mode" et "Retransmission Mode") ne sont pratiquement plus utilisés. L'"ERTM" permet notamment de prendre en compte un nombre maximal donné de retransmissions, une durée maximale donnée pendant laquelle une retransmission peut intervenir et permet d'identifier les paquets non ou mal 25 transmis. Le "SM" est adapté aux flux de données asynchrones. Il prend en compte un paramètre "Flush Timeout" fini. Du côté du récepteur Bluetooth, si la mémoire tampon est pleine, alors les précédentes données sont écrasées. Dans le standard Bluetooth, un paramètre appelé "Retransmission and 30 flow control option", ce qui signifie "option de retransmission et de contrôle 3054399 7 de flux" permet de choisir un mode. Le standard Bluetooth recommande d'établir des liaisons fiables ("reliable" en anglais) limitant les pertes de données, en utilisant un "Basic Mode" avec un "Flush Timeout" infini, ou sur des piles Bluetooth plus récentes l'"ERTM" avec un "Flush Timeout" 5 quelconque. En pratique, aucun produit du marché ne propose de fonction de pilotage A2DP point à multipoints synchronisé pour des dispositifs multimédia Bluetooth quelconques. 10 L'invention vise à améliorer la situation. L'invention se rapporte notamment à un dispositif de pilotage de dispositifs multimédia Bluetooth, le dispositif de pilotage comprenant une puce Bluetooth agencée pour mettre en oeuvre un profil A2DP modifié de 15 façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth, la puce Bluetooth du dispositif de pilotage étant agencée pour diffuser plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, 20 en s'appuyant sur un usage non bloquant de Bluetooth. Ce dispositif est avantageux en ce qu'il permet d'utiliser une seule puce Bluetooth pour piloter plusieurs dispositifs multimédia Bluetooth, alors même que le standard Bluetooth ne prévoit pas une telle possibilité. Il s'avère ainsi possible de modifier le profil A2DP sans contrevenir au 25 standard Bluetooth, en permettant une liaison point à multipoints non prévue dans le standard. Ainsi, on préserve l'interopérabilité (les fonctions Bluetooth sont supportées normalement). Il n'y a pas de violation du standard Bluetooth dans la mesure où le dispositif ne fait qu'ajouter une fonction non initialement prévue sans remettre en cause les fonctions 30 existantes. De plus, l'usage non bloquant de Bluetooth permet d'empêcher une désynchronisation des flux multimédia diffusés. 3054399 8 Le dispositif selon l'invention peut comporter une ou plusieurs des caractéristiques suivantes prises seules ou en combinaison. L'invention se rapporte notamment à un dispositif de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth est agencée, 5 lorsqu'un paquet de flux multimédia qu'elle a transmis à destination d'un dispositif multimédia Bluetooth est perdu, pour renvoyer ledit paquet de flux multimédia audit dispositif multimédia Bluetooth, la puce Bluetooth étant agencée pour déterminer un taux de remplissage d'une mémoire tampon d'au moins un dispositif multimédia Bluetooth, et pour déterminer une durée 10 maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia Bluetooth en fonction du taux de remplissage de la mémoire tampon de l'au moins un dispositif multimédia Bluetooth. L'invention se rapporte notamment à un dispositif de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth est agencée 15 pour générer plusieurs SEP pour piloter les dispositifs multimédia Bluetooth. L'invention se rapporte notamment à un dispositif de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth est agencée pour piloter jusqu'à cinq dispositifs multimédia Bluetooth, en utilisant un codec SBC. 20 L'invention se rapporte notamment à un procédé de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth met en oeuvre un profil A2DP modifié de façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth, la puce Bluetooth diffusant plusieurs flux multimédia 25 liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. L'invention se rapporte notamment à un procédé de pilotage de dispositifs multimédia Bluetooth dans lequel, lorsqu'un paquet de flux 30 multimédia que la puce Bluetooth a transmis à destination d'un dispositif multimédia Bluetooth est perdu, la puce Bluetooth renvoie ledit paquet de 3054399 9 flux multimédia audit dispositif multimédia Bluetooth, et détermine un taux de remplissage d'une mémoire tampon d'au moins un dispositif multimédia Bluetooth, pour en déduire une durée maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia 5 Bluetooth en fonction du taux de remplissage de la mémoire tampon de l'au moins un dispositif multimédia Bluetooth. L'invention se rapporte notamment à un procédé de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth génère plusieurs SEP pour piloter les dispositifs multimédia Bluetooth. 10 L'invention se rapporte notamment à un procédé de pilotage de dispositifs multimédia Bluetooth dans lequel la puce Bluetooth pilote cinq dispositifs multimédia Bluetooth en utilisant un codec SBC. L'invention se rapporte notamment à un programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un 15 processeur, mettent en oeuvre un procédé selon un aspect de l'invention. L'invention se rapporte notamment à un support de stockage non transitoire lisible par ordinateur, stockant un programme d'ordinateur selon un aspect de l'invention. 20 D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la figure 1 illustre un profil A2DP conventionnel ainsi qu'un profil A2DP' selon un mode de réalisation de l'invention agencé pour 25 communiquer avec le profil A2DP conventionnel ; - la figure 2 illustre un système comprenant un dispositif selon un mode de réalisation de l'invention ainsi qu'un ensemble d'enceintes Bluetooth ; - la figure 3 illustre une variante du système de la figure 2. 3054399 10 Les réalisations suivantes sont des exemples. Bien que la description se réfère à un ou plusieurs modes de réalisation, ceci ne signifie pas nécessairement que chaque élément mentionné dans le cadre d'un mode 5 de réalisation ne concerne que ce même mode de réalisation, ou que des caractéristiques de ce mode de réalisation s'appliquent seulement à ce mode de réalisation. La figure 1 illustre une communication entre un profil A2DP' selon un o mode de réalisation de l'invention utilisé par un dispositif maître dit "Source" (qui correspond à un dispositif émettant un flux audio) et un profil A2DP conventionnel utilisé par un dispositif Sink. Le dispositif Sink correspond par exemple à une enceinte Bluetooth, étant entendu qu'une enceinte Bluetooth peut comprendre plusieurs SEPS Sink (plusieurs SEPS Sink peuvent donc 15 correspondre à une même enceinte Bluetooth, chaque SEP Sink pouvant alors correspondre notamment à un codec respectif parmi tous les codecs supportés par cette enceinte Bluetooth). En pratique, les piles Bluetooth des fabricants de puces Bluetooth n'introduisent qu'un seul SEP Source par codec et par puce Bluetooth. Il est 20 donc impossible de connecter plusieurs dispositifs audio (enceintes par exemple) à un téléphone portable, pour un codec donné. Le profil A2DP' se distingue précisément du profil A2DP par une brique AVDTP' utilisée en lieu et place de la brique AVDTP. La brique AVDTP' fournit toutes les fonctions de la brique AVDTP mais en plus permet une 25 connexion point à multipoints synchronisée. La figure 2 illustre un système comprenant au moins trois enceintes Bluetooth SPK1, SPK2 et SPKN associées chacune à un SEP Sink respectif SPEsi, SEPs2, SEPSN (comme évoqué précédemment, chaque enceinte 30 SPK; pourrait être associée à plusieurs SEPS Sink plutôt qu'à un seul SEP 3054399 11 Sink SEPsi, mais pour simplifier seul le SEP Sink effectivement utilisé est représenté). Le système comprend également un dispositif DEV' de pilotage d'enceintes Bluetooth selon une mise en oeuvre possible de l'invention. Le dispositif DEV' comprend une puce Bluetooth BC'. Cette puce Bluetooth BC' 5 stocke un unique SEP USEP l'identifiant. Cette puce Bluetooth BC' établit une liaison point à multipoints LNK' avec les trois enceintes Bluetooth SPK1, SPK2 et SPKN, via des SEP respectifs SEPsi, SEPs2 et SPEsN. La figure 3 illustre un système comprenant au moins trois enceintes 10 Bluetooth SPK1, SPK2 et SPKN associées chacune à un SEP Sink respectif SPEsi, SEPs2, SEPsN (comme évoqué précédemment, chaque enceinte SPK; pourrait être associée à plusieurs SEPS Sink plutôt qu'à un seul SEP Sink SEPsi, mais pour simplifier seul le SEP Sink effectivement utilisé est représenté). Le système comprend également un dispositif DEV de pilotage 15 d'enceintes Bluetooth selon une mise en oeuvre possible de l'invention. Le dispositif DEV comprend une puce Bluetooth BC. Cette puce Bluetooth BC stocke au moins trois SEPS SEP1, SEP2 et SEPN qui simulent trois puces Bluetooth distinctes (mais il s'agit de puces Bluetooth virtuelles car en réalité il n'y en a qu'une). La puce Bluetooth BC établit une liaison point à 20 multipoints LNK avec les au moins trois enceintes Bluetooth SPK1, SPK2 et SPKN, mais du point de vue du standard Bluetooth, cette liaison LNK semble être un ensemble de trois (au moins) liaisons point à point. En effet, le SEP SEP1 est connecté à un SEP SEPsi de l'enceinte SPK1, le SEP SEP2 est connecté à un SEP SEPs2 de l'enceinte SPK2 et le SEP SEPN est 25 connecté à un SEP SEPsN de l'enceinte SPKN. Un premier mode de réalisation se rapporte à un dispositif (par exemple DEV ou DEV') de pilotage de dispositifs multimédia Bluetooth, le dispositif de pilotage comprenant une puce Bluetooth (par exemple BC ou BC'). 30 Les dispositifs multimédia Bluetooth sont par exemple des enceintes Bluetooth. Par enceinte Bluetooth, on désigne tout dispositif Bluetooth 3054399 12 renfermant au moins un haut-parleur agencé pour diffuser un son perceptible simultanément par plusieurs êtres humains. Il peut s'agir par exemple d'une enceinte acoustique pour chaîne Hi-fi, ou encore d'un téléphone portable muni d'un haut parleur prévu pour être audible par 5 plusieurs personnes, dans la mesure où c'est ce haut parleur qui est piloté par le dispositif de pilotage. Plus précisément, on entend par "son perceptible simultanément par plusieurs êtres humains" un son perceptible (au sens où son contenu peut-être distingué) par tout être humain doté d'une ouïe normale placé à une distance d'au moins un mètre de l'enceinte, 10 en présence d'un bruit ambiant correspondant à celui d'une conversation, soit environ 40 dB SPL. Un casque audio, un écouteur intra auriculaire ou encore un écouteur de téléphone ne sont donc pas des enceintes au sens de la présente demande, puisqu'il faut les appliquer dans ou contre l'oreille pour percevoir les sons émis. 15 Selon une mise en oeuvre possible, les dispositifs multimédia Bluetooth sont des écouteurs Bluetooth. De tels écouteurs sont par exemple connectés avec une télévision et nécessitent d'être synchronisés entre eux en plus d'être synchronisés avec un flux vidéo diffusé sur la télévision. Chacun des dispositifs multimédia Bluetooth peut être, plus 20 généralement, une télévision Bluetooth, un écran Bluetooth, un téléphone portable Bluetooth, un ordinateur portable ou de bureau Bluetooth, une tablette Bluetooth, une chaîne Hi-fi Bluetooth, une autoradio Bluetooth, ou encore un baladeur numérique Bluetooth. Le dispositif de pilotage DEV ou DEV' est par exemple une télévision 25 Bluetooth, un écran Bluetooth, un téléphone portable Bluetooth, un ordinateur portable ou de bureau Bluetooth, une tablette Bluetooth, une chaîne Hi-fi Bluetooth, une autoradio Bluetooth, ou encore un baladeur numérique Bluetooth. La puce Bluetooth (par exemple BC ou BC' sur les figures) est agencée 30 pour mettre en oeuvre un profil A2DP modifié (noté A2DP' sur la figure 1) de façon à créer une liaison (par exemple LNK ou LNK') point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth 3054399 13 SPK1, SPK2, SPKN. La puce Bluetooth du dispositif de pilotage est agencée pour diffuser plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth en s'appuyant sur un usage non bloquant 5 de Bluetooth. Par flux multimédia "liés les uns aux autres", on entend que les flux multimédia se rapportent à une même situation (par exemple une même scène, ou une même musique), mais peuvent néanmoins être différents. Par exemple, les flux multimédia peuvent être six flux audio correspondant chacun à l'un des canaux 5.1 d'un enregistrement audio, ou 10 encore peuvent être plusieurs vidéos d'une même scène, filmées en même temps mais de points de vue différents. Le dispositif de pilotage est par exemple agencé pour émettre un flux audio (ou plus généralement multimédia) via une liaison sans fil de type Bluetooth. Par exemple, il stocke ou relaie un flux multimédia comprenant au minimum un canal audio. Par 15 exemple, il stocke des fichiers MP3, ou se connecte à un serveur (tel qu'un serveur Youtube®) à partir duquel il télécharge un flux qu'il retransmet au fur et à mesure, simultanément, via Bluetooth, à plusieurs dispositifs multimédia Bluetooth. En s'appuyant sur un usage non bloquant de Bluetooth au lieu d'un 20 usage bloquant utilisé par défaut en A2DP, le dispositif de pilotage évite des pertes de synchronisation. Par usage non bloquant de Bluetooth, on entend tout paramétrage de Bluetooth (par un mode Bluetooth et/ou par d'autres paramètres Bluetooth) qui évite de bloquer la puce Bluetooth du dispositif de pilotage de dispositifs multimédia Bluetooth. Un usage non bloquant de 25 Bluetooth est donc un usage de Bluetooth qui évite de forcer la puce Bluetooth à réémettre un paquet non reçu tant que celui-ci n'a pas été reçu, et qui évite également de la forcer à réémettre un tel paquet au-delà d'un instant auquel au moins un dispositif multimédia Bluetooth n'a plus de données en mémoire tampon à cause par exemple des tentatives de 30 réémission infructueuses du paquet, qui monopolisent les communications Bluetooth. Un usage non bloquant correspond à un ensemble de paramètres (FTO, QoS, Mode, Extended Flow features) et non uniquement à un mode (tel que le mode SM) au sens du standard Bluetooth. Il s'agit par 3054399 14 exemple du mode "Flow Control" ou de tout mode pour lequel le paramètre "Flush Timeout" est fixé selon le standard Bluetooth pour empêcher toute retransmission. Un usage bloquant est a contrario un usage qui conduit par exemple à réémettre des données tant qu'elles ne sont pas reçues, ou qui 5 conduit à réémettre des données alors qu'un dispositif multimédia Bluetooth davantage prioritaire attendait lui aussi des données et ne les a pas reçues à cause dudit usage (il est alors bloqué). L'usage bloquant est utilisé dans l'art antérieur car il évite des pertes occasionnelles de données (en cas de coupure prolongée pendant une durée supérieure à un seuil donné l'usage 10 bloquant ne permet pas d'éviter des pertes de données). Dans l'hypothèse où l'on adapte Bluetooth pour permettre une diffusion point à multipoints, employer un usage non bloquant évite le risque qu'un dispositif multimédia Bluetooth devienne inaccessible et empêche toute transmission de données à l'ensemble des dispositifs multimédia Bluetooth. Un dispositif multimédia 15 Bluetooth peut devenir inaccessible par exemple parce qu'il a été déplacé hors de portée de la puce Bluetooth du dispositif de pilotage DEV, ou parce qu'il contient une batterie qui s'est vidée, ou pour toute autre raison. Les paramétrages L2CAP par défaut de Bluetooth rappelés en introduction ne conviennent pas à la mise en place d'une liaison 20 synchronisée A2DP d'un dispositif Bluetooth maître vers plusieurs dispositifs Bluetooth esclaves. En effet si l'un des liens établis entre le maître et un esclave (par exemple une enceinte) est configuré avec un "Flush Timeout" infini, et si l'enceinte sort du champ Bluetooth ou si elle est alimentée par une batterie qui s'est vidée, alors les données seront 25 continuellement renvoyées vers celle-ci qui, ne les recevant jamais, bloquera toute autre transmission de données vers les autres dispositifs esclaves (les données étant envoyées de façon séquentielle). Par ailleurs, si le paramètre "Flush Timeout" est défini par défaut, le renvoi des données sur une enceinte pourrait entraîner un décalage temporel entre celle-ci et 30 les autres. En effet, au moment où une enceinte sortie du champ Bluetooth du dispositif Bluetooth maître reviendrait dans ce champ, elle poursuivrait la diffusion du flux à partir de l'instant auquel elle s'était arrêtée en sortant de ce champ. 3054399 15 Selon une mise en oeuvre possible, le dispositif de pilotage de dispositifs multimédia Bluetooth est agencé pour déterminer automatiquement, à partir des différentes configurations supportées par les piles Bluetooth des dispositifs multimédia Bluetooth, le paramétrage à adopter pour chaque 5 canal L2CAP (correspondant à un lien logique entre la puce Bluetooth du dispositif de pilotage d'enceintes Bluetooth et un dispositif multimédia Bluetooth) de façon à garder une liaison synchronisée entre le dispositif de pilotage de dispositifs multimédia Bluetooth et les différents dispositifs multimédias esclaves. Les paramètres L2CAP de chacun des dispositifs 10 multimédia peuvent être différents (ils peuvent dépendre des caractéristiques de ces dispositifs multimédia, de leur aptitude à supporter certains protocoles, etc.). Selon une mise en oeuvre possible, le dispositif de pilotage de dispositifs multimédia Bluetooth est agencé pour configurer l'ensemble des "Flush 15 Timeout" pour les différents canaux L2CAP à la valeur définie par le standard Bluetooth (à savoir 1, mais cela pourrait varier suivant les implémentations) pour qu'aucune retransmission ne soit effectuée. La liaison ainsi obtenue est non fiable au sens où les erreurs ou pertes de transmission ne sont pas rattrapées, mais assure une synchronisation après 20 perte éventuelle de paquets. Selon une mise en oeuvre possible, la modification du profil A2DP consiste à modifier la brique AVDTP utilisée par le profil A2DP, par exemple de l'une des façons indiquées ci-dessous. Afin de réaliser une brique AVDTP' correspondant à une brique AVDTP modifiée, il est possible 25 notamment d'utiliser une implémentation libre telle que l'implémentation dénommée BlueZ (bien connue de l'homme du métier), conçue pour mettre en oeuvre la technologie Bluetooth sur des systèmes d'exploitation de type Linux, et disponible sous licence GNU GPL. L'implémentation BlueZ est devenue une mise en oeuvre Bluetooth de référence pour Linux et a été 30 intégrée au noyau Linux. Selon un deuxième mode de réalisation, la puce Bluetooth d'un dispositif 3054399 16 de pilotage de dispositifs multimédia Bluetooth selon le premier mode de réalisation est agencée, lorsqu'un paquet de flux multimédia qu'elle a transmis à destination d'un dispositif multimédia Bluetooth est perdu, pour renvoyer ledit paquet de flux multimédia audit dispositif multimédia 5 Bluetooth. La puce Bluetooth étant agencée pour déterminer un taux de remplissage d'une mémoire tampon d'au moins un dispositif multimédia Bluetooth SPK1, SPK2, SPKN et pour déterminer une durée maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia Bluetooth en fonction du taux de remplissage de la 10 mémoire tampon de l'au moins un dispositif multimédia Bluetooth. Selon une mise en oeuvre possible, cette durée maximale correspond à la mémoire tampon la moins remplie parmi les mémoires tampon de tous les autres dispositifs multimédia Bluetooth, dont il faut déduire le temps nécessaire pour transmettre une portion suffisante de flux multimédia. On 15 ne prend alors pas en compte le contenu de la mémoire tampon du dispositif multimédia Bluetooth qui a perdu un paquet. Selon une autre mise en oeuvre, cette durée maximale correspond à la mémoire tampon la moins remplie parmi les mémoires tampon de tous les dispositifs multimédia Bluetooth (y compris celui qui a perdu le paquet), dont 20 il faut déduire le temps nécessaire pour transmettre une portion suffisante de flux multimédia. En effet, si le dispositif multimédia Bluetooth qui a perdu le paquet court le risque d'arriver à court de données de flux multimédia à jouer, il peut être considéré plus approprié d'abandonner la tentative de retransmission du paquet perdu qui de toute façon serait restitué de façon 25 retardée et donc désynchronisée des autres dispositifs multimédia Bluetooth. Selon une autre mise en oeuvre, la puce Bluetooth est agencée pour identifier des dispositifs multimédia Bluetooth pour lesquels il n'est pas utile de vérifier le taux de remplissage de la mémoire tampon. Par exemple, la 30 puce Bluetooth peut exclure un nombre n de dispositifs multimédia Bluetooth dont elle a alimenté les mémoires tampon en dernier, si elle peut en déduire qu'il existe nécessairement d'autres dispositifs multimédia 3054399 17 Bluetooth dont la mémoire tampon est moins remplie et qui vont déterminer la durée maximale précitée. Selon une autre mise en oeuvre, la puce Bluetooth est agencée pour mémoriser un identifiant du dispositif multimédia Bluetooth dont elle a 5 alimenté la mémoire tampon depuis le plus longtemps. Lorsqu'un paquet est perdu, la puce Bluetooth ne vérifie alors que la mémoire tampon de ce dispositif multimédia Bluetooth dont elle a alimenté la mémoire tampon depuis le plus longtemps. Selon une mise en oeuvre possible, le dispositif de pilotage est agencé 10 pour transmettre des portions de flux audio d'environ 14ms (ce qui correspond à la durée d'un bloc de flux audio encodé par le codec SBC). Selon une mise en oeuvre possible, le dispositif de pilotage pilote quatre dispositifs multimédia Bluetooth, et la transmission d'une portion d'environ 14ms prend environ 1,3ms. Il faut donc environ 4*1,3ms soit environ 5,2ms 15 pour transmettre environ 14ms de flux aux quatre dispositifs multimédia Bluetooth, ce qui laisse environ 14ms-5,2ms soit environ 8,8ms durant lesquelles le dispositif de pilotage peut identifier les paquets mal ou non transmis et les réémettre. Selon une mise en oeuvre possible, le dispositif de pilotage de dispositifs 20 multimédia Bluetooth est agencé pour configurer le "Flush Timeout" de chaque canal L2CAP en fonction de l'état de remplissage des mémoires tampon des dispositifs multimédia Bluetooth, qu'il doit au préalable estimer par exemple par l'une des méthodes précitées. 25 Selon une mise en oeuvre possible, la puce Bluetooth d'un dispositif de pilotage de dispositifs multimédia Bluetooth selon le premier mode de réalisation est agencée pour générer un SEP unique pour piloter tous les dispositifs multimédia Bluetooth. Plus précisément, le profil A2DP du SEP Source (la puce Bluetooth) est modifié, par exemple en substituant une 30 brique AVDTP conventionnelle par une brique AVDTP' modifiée. La modification consiste à supprimer les restrictions empêchant un SEP 3054399 18 Source de se connecter à plus d'un SEP Sink. Or le standard Bluetooth n'implique pas de faire vérifier, au niveau d'un SEP Sink, que le SEP Source avec lequel il dialogue ne dialogue pas également avec un autre SEP Sink. Il s'avère que l'on peut donc techniquement, à partir d'un même 5 SEP Source, diffuser des flux multimédia (en particulier audio) vers plusieurs SEPS Sink depuis une même puce Bluetooth. Le standard Bluetooth n'autorisant pas une communication d'un SEP Source à plusieurs SEPS Sinks, la présente mise en oeuvre constitue une sorte d'extension au standard Bluetooth, extension qui ne génère pas de 10 difficultés dans la mesure où le standard Bluetooth n'est pas prévu pour détecter une telle extension. Bien entendu, il est possible de prévoir dans le dispositif de pilotage de dispositifs multimédia Bluetooth plusieurs puces Bluetooth agencées chacune pour générer un SEP unique pour piloter les dispositifs multimédia 15 Bluetooth gérés respectivement par chacune d'elles. Par exemple, une puce Bluetooth numéro 1 pourrait gérer les dispositifs multimédia numéros 1 à 5, une puce Bluetooth numéro 2 pourrait gérer les dispositifs multimédia numéros 6 à 10 et une puce Bluetooth numéro 3 pourrait gérer les dispositifs multimédia numéros 11 à 15. En effet, le débit maximum d'une 20 puce Bluetooth limite le nombre de dispositifs multimédia qu'elle peut piloter, et si le nombre de dispositifs multimédia dépasse un seuil donné, ajouter une puce Bluetooth permet de piloter des dispositifs multimédia supplémentaires simultanément. 25 Selon un troisième mode de réalisation, la puce Bluetooth d'un dispositif de pilotage de dispositifs multimédia Bluetooth selon le premier ou le deuxième mode de réalisation est agencée pour générer plusieurs SEP pour piloter les dispositifs multimédia Bluetooth. Selon une mise en oeuvre avantageuse, la puce Bluetooth génère un 30 SEP Source distinct pour chaque SEP Sink (correspondant à chaque dispositif multimédia Bluetooth qu'elle doit piloter). Il s'agit là d'une 3054399 19 alternative de la mise en oeuvre précitée, dans laquelle la puce Bluetooth est davantage conforme au standard Bluetooth. En effet, on a bien en apparence des liens point à point, et non un lien point à multipoints. Mais il s'agit bien sûr d'un artifice, qui consiste à générer une multiplicité de SEPS 5 Source virtuels dans une même puce Bluetooth pour simuler une multiplicité de dispositifs Source là où il n'y a en réalité qu'une seule puce Bluetooth. Bien entendu, il est possible de prévoir dans le dispositif de pilotage de dispositifs multimédia Bluetooth plusieurs puces Bluetooth agencées chacune pour générer autant de SEPS Source que de dispositifs multimédia 10 Bluetooth gérés respectivement par chacune d'elles. Par exemple, une puce Bluetooth numéro 1 pourrait gérer les dispositifs multimédia Bluetooth numéros 1 à 5 à l'aide de SEPS Source respectifs SEP1 à SEP6, une puce Bluetooth numéro 2 pourrait gérer les dispositifs multimédia Bluetooth numéros 6 à 10 à l'aide de SEPS Source respectifs SEP6 à SEPio et une 15 puce Bluetooth numéro 3 pourrait gérer les dispositifs multimédia Bluetooth numéros 11 à 15 à l'aide de SEPS Source respectifs SEPii à SEP16. En effet, le débit maximum d'une puce Bluetooth limite le nombre de dispositifs multimédia qu'elle peut piloter, et si le nombre de dispositifs multimédia dépasse un seuil donné, ajouter une puce Bluetooth permet de piloter des 20 dispositifs multimédia supplémentaires simultanément. Le nombre de SEPS Source générés par une puce Bluetooth n'influe pas la bande passante disponible dans cette puce Bluetooth, qui reste la même mais est partagée entre ces différents SEPS Source. Selon une mise en oeuvre possible, la puce Bluetooth crée un maximum de 7 SEPS sources afin de gérer les 25 dispositifs multimédia Bluetooth qu'elle pilote en utilisant un piconet. Un piconet est un réseau comprenant de 1 à 8 dispositifs Bluetooth, parmi lesquels un unique dispositif Bluetooth maître (c'est-à-dire Source) et jusqu'à 7 dispositifs Bluetooth esclaves (c'est-à-dire Sink), comme c'est spécifié par le standard Bluetooth. La limitation à 7 dispositifs Sink par 30 dispositif Source provient de l'adressage Bluetooth qui identifie chaque dispositif Bluetooth esclave à l'aide de trois bits, la combinaison 000 étant réservée à un mode spécifique dénommé « Connectionless Broadcast » (diffusion sans connexion, en anglais). 3054399 20 Selon un quatrième mode de réalisation, la puce Bluetooth d'un dispositif de pilotage de dispositifs multimédia Bluetooth selon l'un des premier au troisième modes de réalisation est agencée pour piloter jusqu'à cinq 5 dispositifs multimédia Bluetooth, en utilisant un codec SBC. Par "piloter jusqu'à cinq dispositifs multimédia Bluetooth", on entend que quel que soit le flux audio SBC diffusé, il est possible de diffuser ce flux sur cinq enceintes. S'il y a moins de cinq enceintes, c'est a fortiori possible. Un flux audio stéréo de qualité dite qualité CD est échantillonné à 10 44,1 kHz et échantillonne le signal audio sur 16 bits. A chaque seconde, 44100 échantillons de 16 bits sont donc fournis pour la voie gauche et 44100 autres échantillons de 16 bits sont fournis pour la voie droite. Le débit brut d'un tel flux est donc de 44100*2*16 bit/s soit un peu plus de 1,4 Mbit/s. Un tel débit est très important, et il est donc utile de le 15 compresser afin de réduire la bande passante nécessaire lors d'une transmission, en particulier une transmission Bluetooth dont le débit n'est pas très élevé. Pour effectuer cette compression, on utilise des codecs. Le codec SBC est un codec très simple et très efficace. On entend par efficace que le codec SBC ne nécessite que très peu de ressources mémoire et de 20 ressource processeur pour fonctionner. Ceci est très utile pour les puces Bluetooth, qui sont souvent limitées en mémoire en puissance de calcul. Le codec SBC est par ailleurs gratuit. Il est également avantageux car très répandu, et assure ainsi une grande interopérabilité. Cependant, il est assez peu performant du point de vue du taux de compression obtenu et de 25 la qualité audio. Le débit binaire d'un flux audio encodé par un codec SBC est au maximum de 372 kbit/s (dans certains cas, SBC génère un débit binaire plus faible, notamment pour s'adapter à la bande passante disponible, et permet ainsi de piloter le cas échéant plus de cinq dispositifs multimédia Bluetooth). Mais des codecs plus performants existent. Par 30 exemple un codec AAC génère un flux audio compressé d'environ 192 kbit/s de qualité sensiblement équivalente à celle d'un flux SBC à 372 kbit/s. Les codecs apt-X permettent eux aussi des performances améliorées (débit plus faible à qualité équivalente), mais ne sont pas 3054399 21 gratuits. La bande passante Bluetooth pour des dispositifs compatibles EDR (acronyme d'origine anglaise signifiant "Enhanced Data Rate" soit débit de données augmenté) comme les enceintes Bluetooth conventionnelles est 5 de 2,1 Mbit/s. Il est ainsi possible de faire passer au minimum cinq flux encodés par un codec SBC (à 372 kbit/s maximum) dans la bande passante disponible. Selon une mise en oeuvre possible, la puce Bluetooth utilise un codec AAC, ce qui permet en théorie de transmettre dix (quasiment onze) flux 10 encodés en AAC à 192 kbit/s. Il est néanmoins avantageux, selon une mise en oeuvre possible, de limiter le nombre de flux AAC à sept afin de pouvoir mettre en place un piconet selon le standard Bluetooth (qui limite le nombre de dispositifs esclaves à 7). Selon d'autres alternatives, d'autres codecs sont utilisés, et permettent de transmettre jusqu'à sept flux encodés, ou 15 moins si le débit du flux encodé est supérieur à 300 kbit/s (dans ce cas le nombre de flux encodés possibles est égal au rapport de 2100000 par le débit d'un flux encodé exprimé en bit/s). Un cinquième mode de réalisation se rapporte à un procédé de pilotage 20 de dispositifs multimédia Bluetooth par une puce Bluetooth. La puce Bluetooth met en oeuvre un profil A2DP modifié (noté A2DP') de façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth, la puce Bluetooth diffusant plusieurs flux multimédia liés les uns aux autres à destination chacun d'un 25 dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. Selon une mise en oeuvre possible, la puce Bluetooth comprend un processeur et exécute un programme d'ordinateur adapté pour mettre en 30 oeuvre un profil A2DP' de façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth, 3054399 22 la puce Bluetooth diffusant plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. 5 Selon une mise en oeuvre alternative, c'est un dispositif de pilotage de dispositifs multimédia Bluetooth comprenant ladite puce Bluetooth qui comprend également un processeur et exécute un programme d'ordinateur adapté pour mettre en oeuvre un profil A2DP' de façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs 10 multimédia Bluetooth, la puce Bluetooth diffusant plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. Dans les deux mises en oeuvre précitées le programme d'ordinateur est 15 stocké dans une mémoire (par exemple de type EEPROM, Flash ou encore ROM). Cette mémoire peut être implantée dans la puce Bluetooth ou dans le dispositif de pilotage de dispositifs multimédia Bluetooth, hors de la puce Bluetooth. Selon une variante, le programme d'ordinateur est stocké en partie dans la puce Bluetooth, et en partie dans le dispositif de pilotage de 20 dispositifs multimédia Bluetooth. Selon une variante, le dispositif de pilotage de dispositifs multimédia Bluetooth et la puce Bluetooth comprennent chacun au moins un processeur distinct, et exécutent chacun une partie du programme d'ordinateur, qui est stocké soit en un seul lieu (puce mémoire unique) soit de façon distribuée sur plusieurs puces mémoire (par exemple 25 une puce mémoire de la puce Bluetooth et une puce mémoire du dispositif de pilotage de dispositifs multimédia Bluetooth). Selon une autre mise en oeuvre, le procédé est mis en oeuvre non pas par un programme d'ordinateur mais par une puce électronique dédiée, qui est par exemple un FPGA ou tout autre circuit approprié, y compris un 30 circuit ad hoc. Selon une variante, le procédé est mis en oeuvre partiellement par une puce électronique dédiée telle qu'une puce dédiée précitées, et partiellement par un processeur exécutant un programme 3054399 23 d'ordinateur approprié. Selon un sixième mode de réalisation, la puce Bluetooth d'un procédé de pilotage de dispositifs multimédia Bluetooth selon le cinquième mode de 5 réalisation, lorsqu'un paquet de flux multimédia que la puce Bluetooth a transmis à destination d'un dispositif multimédia Bluetooth est perdu, renvoie ledit paquet de flux multimédia audit dispositif multimédia Bluetooth, et détermine un taux de remplissage d'une mémoire tampon de chaque dispositif multimédia Bluetooth SPK1, SPK2, SPKN, pour en déduire une 10 durée maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia Bluetooth en fonction du taux de remplissage de la mémoire tampon des dispositifs multimédia Bluetooth. Selon un septième mode de réalisation, la puce Bluetooth d'un procédé 15 de pilotage de dispositifs multimédia Bluetooth selon le cinquième ou le sixième mode de réalisation génère plusieurs SEPS SEP1, SEP2, ... SEPN pour piloter les dispositifs multimédia Bluetooth SPK1, SPK2, ... SPKN. Selon un huitième mode de réalisation, la puce Bluetooth d'un procédé 20 de pilotage dispositifs multimédia Bluetooth selon l'un des cinquième au septième modes de réalisation pilote cinq dispositifs multimédia Bluetooth en utilisant un codec SBC. Un neuvième mode de réalisation se rapporte à un programme 25 d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en oeuvre un procédé selon l'un des cinquième au huitième modes de réalisation. Ce programme d'ordinateur est par exemple écrit dans un langage bas niveau tel qu'un langage assembleur, ou dans un langage de plus haut niveau et davantage portable, 30 tel que le langage C. Selon une mise en oeuvre possible, le programme 3054399 24 d'ordinateur est divisé en plusieurs modules. Selon une mise en oeuvre possible, les différents modules sont tous écrits dans le même langage, par exemple le langage C ou l'assembleur. Selon une alternative, certains modules sont écrits dans des langages différents, par exemple certains 5 modules sont écrits en langage C, d'autres en langage assembleur. Selon une mise en oeuvre possible, tous les modules sont stockés dans une même mémoire. Selon une alternative, certains modules sont stockés dans des mémoires distinctes. 10 Un dixième mode de réalisation se rapporte à un support de stockage non transitoire lisible par ordinateur, stockant un programme d'ordinateur selon le neuvième mode de réalisation. Selon une mise en oeuvre possible, le support de stockage est une clé USB, une carte SD ou une carte micro SD. Selon une variante, le support de stockage est une carte mémoire 15 quelconque. Selon une autre variante, le support de stockage est une puce mémoire qui a vocation à être montée sur un circuit électronique. Il s'agit par exemple d'une mémoire EEPROM, ROM, ou encore Flash. Selon une variante possible, le support de stockage est un support magnétique (par exemple du type disque dur) ou encore optique (par exemple du type CD ou 20 DVD). L'invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples. Les mémoires utilisables couvrent tout type de mémoire. Les modes de réalisation décrits en relation avec le dispositif de pilotage 25 de dispositifs multimédia Bluetooth peuvent être transposés aux procédés de pilotage de dispositifs multimédia Bluetooth, ainsi qu'aux programmes d'ordinateur et aux supports de stockage du programme selon des modes de réalisation de l'invention, et réciproquement. 30 REVENDICATIONS1. Dispositif (DEV, DEV') de pilotage de dispositifs multimédia Bluetooth, le dispositif de pilotage comprenant une puce Bluetooth (BC, BC') agencée pour mettre en oeuvre un profil A2DP modifié (A2DP') de façon à créer une liaison (LNK, LNK') point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth (SPK1, SPK2, SPKN), la puce Bluetooth du dispositif de pilotage étant agencée pour diffuser plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. 2. Dispositif de pilotage de dispositifs multimédia Bluetooth selon la revendication 1, dans lequel la puce Bluetooth est agencée, lorsqu'un paquet de flux multimédia qu'elle a transmis à destination d'un dispositif multimédia Bluetooth est perdu, pour renvoyer ledit paquet de flux multimédia audit dispositif multimédia Bluetooth, la puce Bluetooth étant agencée pour déterminer un taux de remplissage d'une mémoire tampon d'au moins un dispositif multimédia Bluetooth (SPK1, SPK2, SPKN), et pour déterminer une durée maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia Bluetooth en fonction du taux de remplissage de la mémoire tampon de l'au moins un dispositif multimédia Bluetooth. 3. Dispositif (DEV) de pilotage de dispositifs multimédia Bluetooth selon la revendication 1 ou 2, dans lequel la puce Bluetooth (BC) est agencée pour générer plusieurs SEP pour piloter les dispositifs multimédia Bluetooth. 3054399 26 4. Dispositif de pilotage de dispositifs multimédia Bluetooth selon l'une des revendications précédentes, dans lequel la puce Bluetooth est agencée pour piloter jusqu'à cinq dispositifs multimédia Bluetooth, en utilisant un codec SBC. 5 5. Procédé de pilotage de dispositifs multimédia Bluetooth par une puce Bluetooth, dans lequel la puce Bluetooth met en oeuvre un profil A2DP modifié (A2DP') de façon à créer une liaison point à multipoints depuis ladite puce Bluetooth vers plusieurs dispositifs multimédia Bluetooth, la puce 10 Bluetooth diffusant plusieurs flux multimédia liés les uns aux autres à destination chacun d'un dispositif multimédia Bluetooth respectif parmi lesdits plusieurs dispositifs multimédia Bluetooth, en s'appuyant sur un usage non bloquant de Bluetooth. 15 6. Procédé de pilotage de dispositifs multimédia Bluetooth selon la revendication 5, dans lequel, lorsqu'un paquet de flux multimédia que la puce Bluetooth a transmis à destination d'un dispositif multimédia Bluetooth est perdu, la puce Bluetooth renvoie ledit paquet de flux multimédia audit dispositif multimédia Bluetooth, et détermine un taux de remplissage d'une 20 mémoire tampon d'au moins un dispositif multimédia Bluetooth (SPK1, SPK2, SPKN), pour en déduire une durée maximale pendant laquelle elle peut renvoyer le paquet de flux multimédia perdu au dispositif multimédia Bluetooth en fonction du taux de remplissage de la mémoire tampon de l'au moins un dispositif multimédia Bluetooth. 25 7. Procédé de pilotage de dispositifs multimédia Bluetooth selon la revendication 5 ou 6, dans lequel la puce Bluetooth génère plusieurs SEP (SE P1, SEP2, SEPN) pour piloter les dispositifs multimédia Bluetooth (SPK1, SPK2, SPKN). 30 3054399 27 8. Procédé de pilotage de dispositifs multimédia Bluetooth selon l'une des revendications 5 à 7, dans lequel la puce Bluetooth pilote cinq dispositifs multimédia Bluetooth en utilisant un codec SBC. 5 9. Programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en oeuvre un procédé selon l'une des revendications 5 à 8. 10. Support de stockage non transitoire lisible par ordinateur, stockant un 1 o programme d'ordinateur selon la revendication 9.