FR 2882213 A1 20060818 FR 0501587 A 20050216 TRANSMETTEUR AUDIO SANS FIL SUR INTERNET 5 La présente invention concerne un transmetteur audio sans fil sur internet. Elle s'applique, en particulier, à la transmission unidirectionnelle, par exemple pour la radiodiffusion et à la transmission bidirectionnelle, par exemple la téléphonie. Les moyens de transmission sans fil à courte portée sont de plus en plus utilisés. Parmi ceux-ci, ceux mettant en oeuvre le standard WIFI (acronyme de Wireless-Fidelity ou Internet sans-fil 802.11) connaissent un succès considérable et de nombreux ordinateurs portables et les assistants personnel numériques (en anglais PDA, pour personal digital assistant) sont équipés de cette technologie. Toutefois, la nécessité d'utiliser un ordinateur portable ou un assistant personnel pour mettre en oeuvre le standard Wifi rend cette technologie coûteuse lorsqu'il s'agit d'effectuer une fonction simple comme transmettre du son par radio vers Internet pour un faible coût ou lorsqu'il s'agit d'effectuer une simple conversation téléphonique vers un correspondant sur Internet pour un faible coût.. Les transmissions de son sans fil sont désormais classiques dans les micro HF, mais leur inconvénient principal est de transmettre du son modulé en fréquence ou en amplitude, ce qui les rend sensibles aux parasites. Cet inconvénient a disparu pour partie avec les téléphones mobiles. Toutefois cela suppose l'achat d'un terminal pour un coût parfois élevé, et l'obligation d'un abonnement avec un opérateur. De plus, le son ainsi transmis ne peut pas être envoyé vers internet. Cette contrainte a été levée avec l'arrivée de moyens au standard WIFI depuis maintenant plusieurs années. Il est donc maintenant possible d'enregistrer un flux audio depuis un micro connecté à un ordinateur ou un assistant personnel PDA et de le transmettre vers Internet via une communication WIFI, si l'ordinateur ou l'assistant personnel PDA est équipé d'une carte WIFI. L'inconvénient majeur de cette dernière solution est son coût élevé car il faut disposer d'un ordinateur ou d'un assistant personnel PDA uniquement pour transmettre du son. En outre, l'ordinateur et l'assistant personnel PDA consomment beaucoup d'énergie, ce qui induit une décharge accélérée des batteries et une faible autonomie de fonctionnement pour le système. Certaines solutions embarquées permettent de se passer d'un ordinateur ou d'un assistant personnel PDA pour transmettre du son. Toutefois elles ne permettent pas l'emploi de lecteurs multimedia classiques de type RealPlayer (marque déposée) ou QuickTime (marque déposée) pour écouter le son. La présente invention vise à remédier à ces inconvénients. Elle propose un transmetteur audio/Wifi/Internet unidirectionnel ou bidirectionnel, pour répondre au besoin de transmettre du son par voie hertzienne en utilisant les technologies Wifi et de pouvoir écouter ce son numérisé depuis Internet. La réalisation d'un transmetteur selon la présente invention vise aussi à être bon marché et compacte (par exemple un volume à peine supérieur à celui d'un micro HF classique) et à consommer peu d'énergie. Les transmissions de son sans fil sont désormais classiques dans les téléphones sans fil de type DECT (acronyme de Digital Enhanced Cordless Telephony, pour en français, téléphonie numérique sans-fil améliorée) ou GSM. Mais leur inconvénient principal est d'utiliser des protocoles non compatibles avec internet. Selon un premier aspect, la présente invention vise un transmetteur sans fil, caractérisé en ce qu'il comporte: - un capteur de sons, - un émetteur à courte portée et - un circuit électronique comportant un unique circuit intégré consistant en un microcontrôleur reprogrammable adapté à mettre en oeuvre un standard de communication à courte portée pour transmettre des paquets de données organisées en transmission de flux de données standardisée à une borne d'accès à un réseau informatique, selon un protocole de communication sur ledit réseau informatique. Grâce à ces dispositions, puisque le circuit électronique comporte un unique circuit intégré, sa conception, sa fabrication et sa mise en oeuvre sont simplifiés et de faible coût, encombrement et poids. De plus, puisque le microcontrôleur est reprogrammable, le transmetteur peut évoluer et mettre en oeuvre des programmes qui sont différents selon la configuration matérielle et logicielle et selon les besoins de l'utilisateur. Par exemple, des prétraitements peuvent être effectués sur les signaux captés par le capteur de sons. De plus, en tant que composant reprogrammable, c'est un composant standard du marché et son prix de revient est plus faible qu'un composant spécifique, à capacité de calcul identique. Par exemple, le standard de communication à courte portée est le standard Wifi, la transmission de flux de données répond au standard RTSP (acronyme de Real Time Streaming Protocol que l'on peut traduire en français par Protocole de flux temps-réels Internet) et le protocole de communication sur un réseau informatique est le protocole pour Internet "IP" pour Internet Protocol. Grâce à ces dispositions, le transmetteur, intégrant les piles de protocoles Internet et des moyens de transmission de flux de données (streaming RTSP), rend possible l'emploi de lecteurs multimédia classiques de type RealPlayer pour écouter le son. Selon une variante, la présente invention vise un téléphone Wifi/Internet à microcontrôleur sur circuit imprimé pour répondre au besoin de transmettre et de recevoir du son en duplex intégral sur Internet par voie hertzienne en utilisant les technologies de voix sur IP et de Wifi embarquées dans un microcontrôleur standard et largement répandu, par exemple de la famille MICROCHIP (marque déposée). L'usage d'un microcontrôleur standard garantit l'évolutivité de la solution. Les microcontrôleurs sont de plus en plus puissants et incorporent de plus en plus de fonctions (RAM, ROM, EEPROM, conversion analogique/numérique et numérique/analogique). Chaque aspect de la présente invention s'emploie donc à tirer parti de cette puissance et de cette intégration pour obtenir un ensemble miniaturisé, bon marché, et consommant peu d'énergie. Ainsi, selon des caractéristiques particulières, le microcontrôleur reprogrammable comporte une sortie de signaux sonores destinés à être émis par un transducteur électroacoustique et le microcontrôleur reprogrammable est adapté à mettre en oeuvre un standard de communication à courte portée pour recevoir des paquets de données organisées en transmission de flux de données standardisée depuis ladite borne d'accès à un réseau informatique, selon un protocole de communication sur ledit réseau informatique. Grâce à ces dispositions, le transmetteur peut être bidirectionnel et faire office de téléphone sans fil sur Internet. Selon des caractéristiques particulières, le microcontrôleur reprogrammable pilote une carte Wifi depuis une interface PCMCIA ou Personal Computer Memory Card International Association définie par l'Association Internationale des cartes mémoires pour ordinateur personnel ou depuis une carte Compact Flash. Grâce à ces dispositions, la carte Wifi est de faibles complexité et coût et est aisée à mettre en oeuvre. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole de flux temps-réels Internet RTSP, ou Real Time Streaming Protocol. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole Temps-Réel Internet et Protocole de Contrôle Temps Réel Internet RTP/RTCP, ou Real Time Protocol/Real Time Control Protocol. Grâce à chacune de ces dispositions, la compatibilité avec les standards Internet et multimédias permet au destinataire de diffuser le signal sonore avec de simples lecteurs multimédia tels que RealPlayer et QuickTime plutôt qu'avec des logiciels propriétaires, ce qui aurait été le cas si l'on avait pas utilisé des protocoles standardisés. De plus, cette implémentation se fait avec peu de composants. Selon des caractéristiques particulières, le capteur de sons est relié à une entrée analogique du microcontrôleur reprogrammable. Grâce à ces dispositions, on évite un numériseur externe au microcontrôleur et la complexité de réalisation qui en résulterait. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole de résolution d'adresse ARP ou Address Resolution Protocol. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole Internet IP, ou Internet Protocol. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole universel de datagrammes Internet UDP, ou Universal Datagram Protocol. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole de contrôle de transmision Internet TCP, ou Transmission Control Protocol. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente le protocole de voix sur IP de la norme H323. Grâce à chacune de ces dispositions, les signaux transmis ou reçu par le transmetteur objet de la présente invention peut être échangés avec des systèmes implémentant des protocoles standards. En particulier, la compatibilité avec les standards Internet et multimédias permet de mettre en oeuvre la présente invention avec des progiciels implémentant la norme H323 largement répandus tels que "Netmeeting" et "Openphone" (marques déposées) plutôt qu'avec des logiciels propriétaires, ce qui aurait été le cas si l'on avait pas utilisé des protocoles standardisés. Selon des caractéristiques particulières, le microcontrôleur reprogrammable comporte une interface de sortie en modulation de largeur d'impulsion reliée à une filtre passe-bas et met en oeuvre cette interface pour émettre un signal sonore. Grâce à ces dispositions, la partie émission de signaux sonores est simple, peu onéreuse et fiable. Selon des caractéristiques particulières, le microcontrôleur reprogrammable implémente une adaptation d'un codec 16 bits pour un échantillonnage sur 8 bits. Par exemple, le Codec considéré est le codec PCM-uLaw. Grâce à ces dispositions, un microcontrôleur plus simple, de plus faible coût, par exemple limité en ce qui concerne la numérisation/dénumérisation à huit ou dix bits, peut être utilisé. D'autres avantages, buts et caractéristiques de l'invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés dans lesquels: - la figure 1 représente, schématiquement, un premier mode de réalisation de la présente invention sous forme de transmetteur audiio unidirectionnel, - la figure 2 représente des couches protocolaires mises en oeuvre par le premier mode de réalisation de la présente invention illustré en figure 1, - la figure 3 représente, sous forme de logigramme, des étapes mises en oeuvre par le premier mode de réalisation de la présente invention illustré en figures 1 et 2, - la figure 4 représente, schématiquement, un deuxième mode de réalisation de la présente invention sous forme de transmetteur audio bidirectionnel, - la figure 5 représente des couches protocolaires mises en oeuvre par le deuxième mode de réalisation de la présente invention illustré en figure 4 et - les figures 6A et 6B représentent, sous forme de logigramme, des étapes mises en oeuvre par le deuxième mode de réalisation de la présente invention illustré en figures 4 et 5. Les microcontrôleurs sont de plus en plus puissants et incorporent de plus en plus de fonctions (RAM, ROM, EEPROM, conversion analogique/numérique et numérique/analogique). La mise en oeuvre de la présente invention s'emploie à tirer parti de cette puissance et de cette intégration pour obtenir un ensemble miniaturisé, bon marché, et consommant peu d'énergie. On observe, en figure 1, un premier mode de réalisation de la présente invention, sous forme d'un transmetteur audio unidirectionnel 100. Ce transmetteur 100 est relié à un microphone 105 et comporte, dans un circuit électronique ou module émetteur audio/Wifi/Internet 110, un préamplificateur 115, un microcontrôleur 120, un bus PCMCIA (acronyme de Personal Computer Memory Card International Association que l'on peut traduire en français par Association Internationale des cartes mémoires pour ordinateur personnel) 125 et une carte Wifi PCMCIA 130. Les;signaux émis par la carte Wifi PCMCIA 130 sont reçus par un point d'accès Wifi 135 et transmis, par l'intermédiaire du réseau informatique Internet 140, à un ordinateur 145 comportant des haut-parleurs 150. De manière caractéristique, le circuit électronique 110 comporte un unique circuit intégré consistant en le microcontrôleur 120. Dans le mode de réalisation particulier illustré en figure 1, le rnicrocontrôleur 120 est de type reprogrammable, par exemple de la famille PIC18F. II se charge de numériser le signal sonore provenant du microphone 105, par l'intermédiaire du préamplificateur 115 et de piloter la carte Wifi 130 depuis une interface PCMCIA ou Compact Flash. Le signal Wifi issu du module émetteur 110 est capté par la borne Wifi 135 qui se charge de le relayer vers Internet 140. Un ordinateur 145 équipé d'un lecteur RealPlayer ou QuickTime peut alors jouer le son reçu depuis Internet 140. Le transmetteur illustré en figure 1 présente une importante miniaturisation de sa partie mobile, c'est-à-dire le module émetteur 110, tout en utilisant des composants et des protocoles standardisés. En outre, l'intelligence du système est répartie entre le microcontrôleur 120, qui gère les protocoles Internet et la numérisation du son, et la carte Wifi 130, qui gère la transmission sans fil (en anglais "wireless"). Le fait d'utiliser un microcontrôleur 120 de la famille Microchip (marque déposée) PIC 18F autorise une évolutivité accrue et aisée des fonctionnalités du transmetteur audio sans fil. Ce module émetteur 110 implémente les protocoles RTSP RTF'/RTCP (acronyme de Real Time Protocol/Real Time Control Protocol que l'on peut traduire en français par Protocole TempsRéel Internet et Protocole de Contrôle Temps Réel Internet) avec peu de composants. Cette compatibilité avec les standards Internet et multimédias permet de mettre en oeuvre la présente invention avec de simples lecteurs multimédia tels que RealPlayer et QuickTime plutôt qu'avec des logiciels propriétaires, ce qui aurait été le cas si l'on avait pas utilisé des protocoles standardisés. Le microphone 105 est constitué d'une pastille électret qui amplifie déjà le signal par un transistor interne. Les signaux audio sont ensuite transmis au pré-amplificateur micro 115 dont le rôle est d'amplifier le signal avant de le transmettre au microcontrôleur 120. Le préamplificateur micro 115 est classique: il n'inclut qu'un seul transistor NPN BC548 polarisé en tension sur sa base avec un condensateur de découplage. Le microcontrôleur 120, de type PIC18F452 de Microchip, dispose d'une capacité de 32 koctets de mémoire morte ROM et d'une mémoire vive RAM dynamique de 1536 octets. Il dispose en outre de huit entrées analogiques et de trente quatre ports d'entrées-sorties. Le microcontrôleur 120 utilise huit lignes de données pour transmettre vers ou recevoir des données de la carte PCMCIA et onze lignes d'adresses. Il y a par ailleurs six lignes de contrôle qui permettent de piloter la carte ou de recevoir des informations de contrôle. Dans le cas du mode de réalisation particulier illustré en figure 1, on n'utilise qu'un seul port analogique sur lequel est transmis le signal audio pré-amplifié. Le microcontrôleur 120 est relié à la carte Wifi 130 par l'intermédiaire d'une interface PCMCIA qui permet de connecter des cartes Wifi PCMCIA ou compact flash (marque déposée) par l'intermédiaire d'un adaptateur. En ce qui concerne l'interface WIFI, le mode de réalisation illustré en figure 1 est compatible avec le circuit imprimé chipset WIFI Prism II d'Intersil (marque déposée) et fonctionne avec des cartes équipées de ce chipset. Les fonctions nécessaires au dialogue entre le microcontrôleur 120 et le circuit imprimé chipset Prism Il sont implémentées sur la base de la documentation technique décrivant le logiciel propriétaire (en anglais "firmwaire") "PRISMII". En ce qui concerne la pile de protocoles Internet, le module de transmission audio supporte les protocoles Internet suivants: - ARP (acronyme de Address Resolution Protocol que l'on peut traduire en français par Protocole de Résolution d'Adresses) pour la résolution d'adresse, - IP (acronyme de Internet Protocol pour protocole Internet), ICMP (acronyme de Internet control message protocol, pour protocole de messages de contrôles Internet), - UDP (acronyme de Universal Datagram Protocol que l'on peut traduire en français par Protocole Universel de Datagrammes Internet), - TCP (acronyme de Transmission Control Protocol que l'on peut traduire en français par Protocole de contrôle de transmission Internet), - HTTP (acronyme de Hypertext Transfer Protocol que l'on peut traduire en français par Protocole de transfert hypertexte Internet), - RTSP et - RTPIRTCP. Etant donné l'espace mémoire réduit dans le microcontrôleur, seule une implémentation simplifiée de ces protocoles est effectuée dans le mode de réalisation illustré en figure 1. Cette pile de protocoles réduite et optimisée est représentée en figure 2 qui montre la manière dont se superposent les couches protocolaires. En ce qui concerne l'étage d'alimentation, le transmetteur peut être alimenté au moyen d'une pile 9 volts, dont l'essentiel de l'énergie est consommée par la carte Wifi. Toute autre type d'alimentation de type 9 Volts régulée peut convenir. En ce qui concerne la mise en oeuvre de l'invention, un transmetteur a été testé avec succès en utilisant une carte Wifi Netgear (marque déposée) MA401 et une carte Wifi Inventel Airline (marques déposées) SNI 1 P, chacune de ces cartes étant équipée du circuit imprimé chipset Prism II (marque déposée). La communication vers Internet s'effectue au travers d'un point d'accès Wifi. Dans le mode de réalisation testé, ce point d'accès est une borne AP1200 de Cisco (marque déposée) mais n'importe quel autre routeur wifi 802.11B peut être utilisé. On observe que, dans une variante de la présente invention, la communication Wifi peut exploiter le mode Ad-hoc plutôt que le mode Infrastructure. Dans ce cas, la communication s'effectue en point à point avec un correspondant situé à proximité, et une borne Wifi relais n'est plus nécessaire. Les ordinateurs reliés au point d'accès en même temps que le module de transmission audio dialoguent avec ce module dès lors qu'ils supportent les protocoles cités précédemment. Pour pouvoir écouter le flux audio depuis un autre ordinateur, il suffit d'avoir installé un lecteur multimédia qui supporte les protocoles RTSP et RTP/RTCP. Dans le mode de réalisation testé, l'écoute fonctionne avec des lecteurs tels que RealPlayer ou QuickTime. Le lecteur Windows Media (marques déposées) ne supportant pas encore RTP mais uniquement MMS (marque déposée) ne peut donc pas encore lire les flux audio dans cet exemple particulier de réalisation. Une variante de la présente invention peut toutefois supporter MMS par une extension du programme stocké dans le microcontrôleur. On observe, en figure 2, à la base de cette pile de couches protocolaires, l'interface PCMCIA, puis, en montant, le standard 802. 11b/802.3, la couche MAC, la couche LLC/SNAP, les standards IP et ARP, les standards TCP, UDP et ICMP, puis les standards HTTP, RTSP et RTP/RTCP et, en couche la plus haute, les standards HTML, SDP et Codec PCMu-Law. On observe que les standards http et HTML ne sont utilisés, dans ce mode de réalisation, pour savoir si un utilisateur distant écoute le flux audio et éventuellement, pour qu'un site de la toile puisse paramétrer dynamiquement la configuration du transmetteur objet de la présente invention. Ces standards sont donc optionnels pour la mise en oeuvre de la présente invention. En ce qui concerne l'encodage du son, celui--ci est encodé au format PCM u-Law, ce qui est un format très répandu. Il correspond au profil 0 dans la liste des profils audio vidéo. Le flux est échantillonné à une fréquence de 8 khz soit un échantillon tous les 125 micro-secondes. Le fonctionnement du module logiciel du microcontrôleur 120 est illustré en figure 3. On observe, en figure 3, une étape d'initialisation du système 305 qui s'effectue à la mise sous tension. Au cours de cette étape 305, le microcontrôleur 120 lance la fonction principale "main", qui effectue les tâches suivantes: - initialisation des ports d'entrée-sorties, initialisation du pilote (en anglais "driver") PCMCIA par un appel à la fonction "PCMCIA_Init". Cette fonction détecte la présence de la carte PCMCIA, effectue un initialisation logicielle ("Soft Reset") de cette carte, et la bascule en mode entrée/sortie ("Input/Output"), initialisation du pilote WIFI/PRISMII en mode "Station" par un appel à la fonction "PRISMII_Init_STA". Cette fonction initialise le logiciel propriétaire PRISMII, alloue les mémoires tampon ("buffers") de transmission, et initialise l'adresse MAC (acronyme de Machine Address Code, pour, en français Adresse codée de la machine) de la carte Wifi (dans l'exemple, l'adresse MAC a pour valeur 00:34:56:78:9A:BC). Après l'initialisation du module émetteur audio 110, le microcontrôleur 120 l'associe au point d'accès Wifi 135, étape 310. Dans l'exemple illustré en figures 1 à 3, le module émetteur 110 cherche à s'associer au SSID (acronyme de Service Set Identifier, pour, en français Identifiant de Service Radio) cible tsunami . Le module émetteur 110 effectue d'abord une recherche des SSID présents au moyen de la fonction "Scan". Une fois le SSID cible détecté, le module émetteur 110 lance la procédure d'association au moyen de la fonction "Join". Si l'opération d'association s'est bien déroulée, le module émetteur audio est en mesure de transmettre et de recevoir des paquets de données. Après association, la fonction principale "main" rentre dans une boucle infinie qui scrute la mémoire tampon "buffer" de réception de la carte Wifi 130, étape 315, au moyen de la fonction "WaitRx". Cette fonction renvoie true Si un paquet a été reçu, sinon false . En ce qui concerne le traitement des protocoles ARP, ICMP et TCP, étape 335 qui est effectuée si un paquet a été reçu, le traitement de ce paquet est confié à la fonction "ProcessRx". cette fonction extrait d'abord l'entête "LLC/SNAP" du paquet et vérifie qu'il s'agit bien d'un paquet IP ou ARP à destination du transmetteur audio. Si ce n'est pas le cas, le paquet est détruit. En cas de réception d'un paquet IP (code LL.CSNAP/PID 0x800), la fonction "ProcessRx" teste s'il s'agit d'un paquet TCP, étape 340. Si le paquet IP est de type ICMP (acronyme de Internet Control Message Protocol, pour, en français Protocole de Messages de Contrôles Internet), la fonction "ProcessRx" envoie une réponse à l'expéditeur en appelant la fonction "SendICMPReply", étape 345. Si le paquet est de type ARP (code LLCSNAP/PID 0x806), la fonction "ProcessRx" envoie une réponse en appelant la fonction "SendARPReply", étape 345. Puis, on retourne à l'étape 315. Si le paquet est de type TCP, la fonction "ProcessRx" teste d'abord s'il s'agit d'un paquet HTTP ou RTSP, étape 350. Si ce n'est pas Ile cas, le paquet est détruit, et on retourne à l'étape 315. Selon l'émetteur du paquet, le port source, et le port destination, la fonction ProcessRx détermine si une session TCP a déjà été ouverte et modifie les paramètres de session en conséquence, ou bien iniitialise une nouvelle session TCP. Le paquet et le numéro de session TCP sont alors transmis à la fonction "ProcessTCPPacket". Cette fonction traite la machine à état TCP et gère donc les signaux de synchronisation TCP-SYN, d'accusé de réception TCPACK, et la fonction de fin de communication TCP-FIN. Si le paquet est HTTP, au cours d'une étape 355, la fonction "ProcessTCPPacket" évalue la chaîne GET reçue par le transmetteur audio et répond en envoyant une réponse HTTP suivie d'une page Web écrite en HTML (la page Web d'un site contenu dans la mémoire du microcontrôleur affiche par exemple une information indiquant si un client à l'écoute du flux, ou stream, audio est connecté : cette connexion est le résultat d'une négociation entre les deux partenaires selon le protocole RTSP). Puis on retourne à l'étape 315. Si le paquet est RTSP, pour le traitement du protocole RTSP, au cours d'une étape 360, la fonction "ProcessTCPPacket" évalue la chaîne de caractères reçue par le transmetteur audio et répond en envoyant une réponse RTSP adaptée à la requête RTSP. Les mots-clés supportés sont "OPTIONS", "DESCRIBE", "SETUP", "PLAY" et "TEARDOWN" (ces mots-clés sont décrits précisément dans la norme IETF RFC 2326 qui décrit le protocole RTSP). Au cours d'une étape 365, on détermine si la chaîne RTSP reçue est le mot "PLAY". Sinon, au cours d'une étape 370, la fonction "ProcessTCPPacket" envoie la réponse RTSP adéquate et retourne à l'étape 315. En ce qui concerne cet envoi d'une réponse RTSP, lors de la requête "DESCRIBE", le transmetteur audio envoie une réponse respectant le protocole SDP, en renseignant notamment les champs version , media , control . Lors de la requête "SETUP", le transmetteur récupère l'adresse des ports clients RTP et RTCP, et envoie en retour ses propres ports RTP et RTCP (4096 et 4097 dans l'implémentation du prototype). Si la chaîne RTSP reçue est le mot "PLAY", l'envoi de paquets audio peut débuter après mémorisation du destinataire, étape 375 et on retourne à l'étape 370. L'émetteur considère que l'envoi des paquets RTP/UDP audio vers le récepteur peut débuter. L'adresse IP et les ports RTP et RTCP du destinataire sont mémorisés. La fonction "ProcessTCPPacket" envoie la réponse RTSP, étape 370 et sort avec le code retour 0x11 pour indiquer le début de l'envoi des paquets audio. La fonction principale "main" active alors les interruptions timers avec une fréquence de 8000Hz soit une période de 125 micro-secondes. Si le résultat de l'étape 315 est négatif, c'est-à-dire si aucun paquet n'a été reçu, au cours d'une étape 320, on effectue le traitement audio RTP/RTCP et la fonction principale "main" appelle ce traitement dans sa boucle infinie. Chaque fois que la mémoire tampon buffer tournant est remplie, le contenu de la mémoire tampon buffer tournant est transféré clans une mémoire tampon buffer de transmission RTP après avoir été converti avec le codeur-décodeur (ou codec) "PCM-ULaw". Puis, au cours d'une étape 325, on teste la présence de destinataire audio RTP/RTCP: si un destinataire RTP/RTCP est identifié (code 0x11 renvoyé par la fonction "ProcessTCPPacket"), l'envoi du paquet peut démarrer, sinon on retourne à la boucle infinie, par l'étape 315. Pendant l'envoi d'un paquet UDP/RTP, étape 330, le contenu de la mémoire tampon buffer de transmission est envoyé à la fonction "SncIRTPPacket" dont le rôle est d'envoyer le paquet audio RTP vers le destinataire via la liaison Wifi. Le paquet RTP est complété avec les informations séquentielles et temporelles (par la fonction "TimeStamps") permettant au récepteur de savoir comment ordonnancer les paquets reçus. Puis on retourne à l'étape 315. Lors d'une interruption de l'horloge "timer", étape 380, cette interruption étant activée par la fonction principale "main" lorsqu'un destinataire RTP/RTCP est identifié, le microcontrôleur 120 transfère la main à la routine d'interruption "clock_isr" et revient au programme principal par l'étape 315 à l'issue de la routine d'interruption. Le microcontrôleur génère automatiquement l'interruption "TIMERO" dès que le compteur "TIMERO" s'annule. Il est donc nécessaire de réinitialiser ce compteur dans la routine d'interruption afin qu'une nouvelle interruption puisse être générée. En ce qui concerne la conversion analogique/numérique, étape 385, outre l'initialisation du compteur "TIMERO", la fonction "clock_isr" récupère le résultat de la conversion analogique-numérique sur le port ANO. Cette conversion prend environ 20 microsecondes, ce qui reste compatible avec la fréquence d'échantillonnage de 8000 Hz qui nécessite une mesure toutes les 125 micro-secondes. Puis, au cours d'une étape 390, on procède à l'écriture dans la mémoire tampon buffer tournant, une fois l'échantillonnage audio effectué, le résultat de la conversion étant inscrit dans la mémoire tampon buffer tournant. L'index de la mémoire tampon buffer est incrémenté pour préparer la prochaine écriture. La routine d'interruption peut alors rendre la main au programme principal. Dans le deuxième mode de réalisation illustré en figures 4 à 6B et adapté à la téléphonie sans fil Wifi sur Internet, le microcontrôleur est, par exemple, celui de référence PIC18F452, de la famille MICROCHIP PIC18F (marque déposée). Il se charge de numériser le son ainsi que de piloter la carte Wifi depuis l'interface PCMCIA. Il restitue également le son vers des hauts parleurs grâce à son interface PWM (acronyme de Pulse Width Modulation pour modulation en largeur d'impulsion). Le signal Wifi issu du transmetteur téléphonique est capté par une borne Wifi qui se charge de le relayer vers internet. Un ordinateur équipé d'un progiciel implémentant le standard H323 de type "NetMeeting" ou "openphone" (marques déposées) peut alors jouer le son reçu depuis Internet et y répondre de façon interactive. Un des intérêts de ce mode de réalisation réside dans sa grande miniaturisation et dans son évolutivité tout en utilisant des composants usuels et des protocoles standardisés de transmission sans fil et de voix sur IP. En outre, l'intelligence du système est répartie entre le microcontrôleur qui gère les protocoles Internet, la numérisation/dénumérisation du son et la carte wifi qui gère la transmission sans fil. Le fait d'utiliser un microcontrôleur de la famille Microchip PIC18F autorise une évolutivité accrue et aisée des fonctionnalités du transmetteur téléphonique, ainsi qu'un coût de fabrication limité. Par ailleurs, il n'existe pas de produits aussi simples qui sache implémenter les protocoles de la norme H323 dans un microcontrôleur polyvalent. Cette compatibilité avec les standards Internet et multimédias permet de mettre en oeuvre la présente invention avec des progiciels implémentant la norme H323 largement répandus tels que "Netmeeting" et "Openphone" plutôt qu'avec des logiciels propriétaires, ce qui aurait été le cas si l'on avait pas utilisé des protocoles standardisés. On observe, en figure 4, un transmetteur téléphonique 400 relié à un microphone 405 et qui comporte, dans un circuit électronique ou module émetteur-diffuseur audio/Wifi/Internet 410, un préamplificateur 415, un microcontrôleur 420, un bus PCMCIA 425, une carte Wifi PCMCIA 430, un étage filtre passe-bas 460 et un haut-parleur 465. Les signaux émis par la carte Wifi PCMCIA 430 sont reçus par un point d'accès Wifi 435 et transmis, par l'intermédiaire du réseau informatique Internet 440, à un ordinateur 445 comportant des haut-parleurs 450. Inversement, des sons captés au niveau de l'ordinateur 445 par un microphone 455 sont transmis, par l'intermédiaire de l'ordinateur 445 et d'Internet 440 au point d'accès Wifi 435, où ils sont transmis au module 410. De manière caractéristique, le circuit électronique 410 comporte un unique circuit intégré consistant en le microcontrôleur 420. En ce qui concerne l'étage haut-parleur, la sortie sonore s'effectue sur la broche PWM du microcontrôleur 420, la largeur de l'impulsion étant directernent proportionnelle à la tension du signal à restituer. Le filtre passif passe-bas, par exemple à réseau RC, 460 convertit le signal issu de la broche de modulation en largeur d'impulsion PWM du microcontrôleur 420. Le filtre passe-bas 460 a, par exemple, une bande passante à -3dB de 8000 Hz. Le signal issu du filtre 460 est ensuite adapté en impédance par un montage émetteur-suiveur utilisant un transistor BC548 (non représenté). Après cette adaptation d'impédance, le signal est susceptible d'attaquer un haut- parleur 465 ayant une impédance supérieure ou égale à 1 Kohms, ce qui est compatible avec les hauts-parleurs équipant les casques audio. En ce qui concerne l'étage microcontrôleur, le microcontrôleur 420 est de type reprogrammable, par exemple de type PIC18F452 de Microchip, dispose d'une capacité de 32 koctets de mémoire morte ROM et d'une mémoire vive RAM dynamique de 1536 octets. Il dispose en outre de huit entrées analogiques et de trente quatre ports d'entrées-sorties. Dans le mode de réalisation testé, on n'utilise qu'un seul port analogique sur lequel est transmis le signal audio pré-amplifié. Pour pouvoir répondre aux contraintes temps-réel liées à l'interactivité, le microcontrôleur 420 est, par exemple cadencé à une vitesse de 40Mhz, ce qui permet d'obtenir une puissance de 10Mips. Le microcontrôleur 420 est relié à la carte Wifi 430 par l'intermédiaire d'une interface PCMCIA. Cette interface PCMCIA permet de connecter des cartes VVifi PCMCIA ou compact flash par l'intermédiaire d'un adaptateur. Le microcontrôleur 420 utilise huit lignes de données pour transmettre vers ou recevoir des données de la carte PCMCIA et onze lignes d'adresses. Il y a par ailleurs six lignes de contrôle qui permettent de piloter la carte ou de recevoir des informations de contrôle. En ce qui concerne l'interface Wifi, on met en oeuvre le circuit imprimé chipset Wifi Prism II d'Intersil. En ce qui concerne l'étage alimentation, le prototype a été alimentée au moyen d'une pile 9 volts, dont l'essentiel de l'énergie est consommée par la carte Wifi. Toute autre type d'alimentation régulée de type 9 volts peut cependant convenir. En ce qui concerne la mise en oeuvre de l'invention, un transmetteur téléphonique a été testé avec succès en utilisant une carte Wifi Netgear MA401 (marque déposée) et une carte Wifi Inventel Airline (marques déposées) SN11P, chacune de ces cartes étant équipée du circuit imprimé chipset Prism II d'InterSil. La communication vers Internet s'effectue au travers d'un point d'accès Wifi. Dans le cas du prototype, ce point d'accès est une borne AP1200 de Cisco mais n'importe quel autre routeur wifi 802.11B peut être utilisé. Les ordinateurs reliés au point d'accès en même temps que le téléphone Wifi à microcontrôleur Microchip peut dialoguer avec ce module dès lors qu'ils supportent les protocoles H323 cités précédemment. Pour pouvoir dialoguer en voix sur IP avec le téléphone Wifi depuis un autre ordinateur, il suffit d'utiliser un progiciel H323 tel que Netmeeting livré en standard sous Windows ou bien OpenPhone depuis un PC sous Linux (marque déposée). A l'heure actuelle la mise en oeuvre de l'invention a été testée avec succès en utilisant ces progiciels. En ce qui concerne la pile de protocoles Internet, le module de transmission audio supporte les protocoles Internet suivants: - ARP pour la résolution d'adresse, - IP pour Internet, - ICMP Internet message protocole, - UDP, - TCP, - HTTP, - H323 pour la pile de protocole de voix sur IP qui inclut - Q931, - H225 avec encodage ASN.1 PER, - H245 avec encodage ASN.1 PER et - RTP/RTCP. Seule une implémentation réduite de ces protocoles est implémentée pour pouvoir fonctionner dans un espace mémoire très réduit. Cette pile de protocoles réduite et optimisée est décrite, par la manière dont se superposent les couches protocolaires, en figure 5. On observe, en figure 5, à la base de cette pile de couches protocolaires, l'interface PCMCIA, puis, en montant, le standard 802. 11b/80:2.3, la couche MAC, la couche l_LC/SNAP, les standards IP et ARP, les standards TCP, UDP et ICMP, puis les standards HTTP, H323 (comportant les standards Q931, H225 et H245) et RTP/RTCP et, en couche la plus haute, les standards HTML et Codec PCMu-Law. En ce qui concerne l'encodage et le décodage du son, le transmetteur téléphonique encode et décode le son au format PCMu-Law. Il correspond au profil 0 dans la liste des profils audio vidéo. Le flux est échantillonné à une fréquence de 8 khz soit un échantillon tous les 125 micro-secondes. Des algorithmes spécifiques sont développés pour supporter le codec PCMuLaw en format d'échantillon codé sur 8 bits alors que la spécification initiale prévoit des échantillons de 16 bits. En effet, le microcontrôleur PIC18F452 à une limite technique de 10 bits pour la numérisation/dénumérisation qui, dans le mode de réalisation décrit, a nécessité une adaptation du codec. Le module logiciel microcontrôleur est décrit en regard des figures 6A et 6B. L'initialisation du système s'effectue à la mise sous tension, étape 605. Le rnicrocontrôleur 420 lance la fonction principale "main", qui effectue les tâches suivantes: - initialisation des ports d'entréesorties, - pré-remplissage de l'entête du paquet RTP, -initialisation du pilote PCMCIA par un appel à la fonction "PCMCIA_Init". Cette fonction détecte la présence de la carte PCMCIA, effectue une remise à zéro logicielle ("Soft Reset") de cette carte, et la bascule en mode Input/Output, - initialisation du pilote Wifi/PRISMII en mode "Station" par uni appel à la fonction "PRISMII_Init_STA" : cette fonction initialise le logiciel propriétaire ("firmware") PRISMII, alloue les mémoires tampons buffers de transmission, et initialise l'adresse MAC de la carte Wifi (dans notre exemple, l'adresse MAC a pour valeur 00:34:56:78:9A:BC). Puis, au cours d'une étape 610, le microcontrôleur procède à l'association du transmetteur téléphonique 400 au point d'accès Wifi 435. Dans notre exemple le système cherche à s'associer au SSID cible tsunami . Le transmetteur téléphonique Wifi effectue d'abord une recherche des SSID présents au moyen de la fonction "Scan". Une fois le SSID cible détecté, le microcontrôleur lance la procédure d'association au moyen de la fonction "Join". Si l'opération d'association s'est bien déroulée, le transmetteur téléphonique Wifi est en mesure de transmettre et de recevoir des paquets par l'intermédiaire du point d'accès Wifi 435. Au cours d'une étape 615, on effectue un test de réception de paquet, la fonction principale "main" rentrant dans une boucle infinie qui scrute d'abord la mémoire tampon buffer de réception de la carte Wifi au moyen de la fonction "WaitRx". Cette fonction renvoie la valeur true Si un paquet a été reçu, sinon elle renvoie la valeur false . Si un paquet a été reçu, au cours d'une étape 640, on effectue le traitement des protocoles ARP, ICMP, TCP et UDP, le traitement clu paquet étant confié à la fonction "ProcessRx". Cette fonction extrait d'abord l'entête ILLC/SNAP du paquet et vérifie qu'il s'agit bien d'un paquet IP ou ARP à destination du téléphone Wifi. Si ce n'est pas le cas, le paquet est détruit. Puis, au cours d'une étape 645, on effectue un test pour déterminer le type de paquet reçu. Si le paquet est de type TCP, au cours d'une étape 675, la fonction "ProcessRx" teste s'il s'agit d'un paquet HTTP ou H323 (ce qui inclut aussi les paquets H245 qui font partie de la pile de protocoles H323). Si ce n'est pas le cas, le paquet est détruit. Selon l'émetteur du paquet, le port source, et le port destination, la fonction détermine si une session TCP a déjà été ouverte et modifie les paramètres de session en conséquence, ou bien initialise une nouvelle session TCP. Le paquet et le numéro de session TCP sont alors transmis à la fonction "ProcessTCPPacket". Cette fonction traite la machine à état TCP et gère donc les signaux de synchronisation "TCP-SYN", d'accusé de réception "TCPACK", et de fin de communication "TCP-FIN". Si le paquet est conforme au standard H323, pour le traitement du protocole H323, la fonction "ProcessTCPPacket" évalue le port du protocole TCP, étape 680. S'il s'agit du port H323 (1720), la fonction effectue alors le traitement des protocoles Q931, étape 685 et H225, étape 690. Si il s'agit du port H245, la fonction "Opère" effectue alors le traitement du protocole H245, étape 695. En ce qui concerne le traitement selon le protocole Q931, étape 685, la fonction "ProcessTCPPacket" récupère d'abord le numéro cle référence de l'appel Q931 et vérifie qu'il s'agit bien d'un paquet SETUP . Si c'est le cas, la fonction ProcessTCPPacket renvoie un paquet Q931 CONNECT correspondant au numéro de référence de l'appel téléphonique et ajoute l'information Display avec pour valeur INCS . Ensuite les informations correspondant au protocole H225 sont ajoutées au paquet Q931 dans le champ User-User . En ce qui concerne le traitement protocole H225, étape 690, la fonction "ProcessTCPPacket" ajoute les informations H225 au paquet Q931 sous le format ASN.1 avec encodage PER. Le champ H323_message_body a pour valeur connect . Le champ H245Address a pour adresse IP, l'adresse du téléphone Wifi, et le port de communication H245 est renseigné. Le champ ConferencelD est également renseigné. Par ailleurs, le champ H245 Tunneling a pour valeur false , ce qui signifie que les paquets H245 ne seront pas encapsulés dans les paquets H225. Le paquet H225 encapsulé dans le paquet Q931 est ensuite envoyé à l'appelant. En ce qui concerne le traitement selon le protocole H245, étape 695, dans un premier temps, la fonction "ProcessTCPPacket" construit un tableau où sont stockés les paramètres des messages requêtes ou réponses envoyés par l'appelant au fur et à mesure que les paquets H245 fragmentés arrivent sur le port H245. Cette opération nécessite un décodage des paquets codés en ASN.1 PER. Une fois que l'appelant à terminé son envoi de fragments de paquet, le traitement et l'analyse des messages et réponses H245 peut commencer. Dans le cas d'une requête de type MasterSlaveDetermination , une réponse de type MasterSlaveDeterminationAck avec décision master est renvoyée à l'appelant. Dans le cas d'une requête de type TerminalCapabilitySet ., une réponse de type TerminalCapabilitySetAck avec un numéro de séquence identique à celui de la requête est renvoyé. Une requête de type TerminalCapabilitySet est ajoutée à la réponse renvoyée à l'appelant. Cette requête précise que le téléphone Wifi supporte le Codec G711 Ulaw, avec des paquets RTP allant jusqu'à 256 octets. Dans le cas d'une requête de type OpenLogicalChannel , une réponse de type OpenLogicalChannelAck est renvoyée avec un LogicalChannelNumber identique à la requête. Les champs MediaChannel et MediaControlChannel sont renseignés avec l'adresse IP et les ports RTP/RTCP du téléphone Wifi. Dans le cas d'une réponse de type MasterSlaveDeterminationAck , le transmetteur téléphonique Wifi renvoie à l'appelant une requête de type OpenLogicalChannel . Le champ MediaControliChannel de la requête est renseigné avec le port RTCP et l'adresse IP du téléphone Wifi. Dans le cas d'une commande de type EndSessionCommarid , ce message de commande indique au téléphone Wifi que la session H323 doit s'achever. La fonction "ProcessTCPPacket" renvoie alors un code retour 0x12 indiquant l'achèvement de la session H323 et donc l'arrêt des flux audio. Puis, au cours d'une étape 700, on teste si la réponse est de type OpenLogicalChannelAck (correspondant à "OpenLogAck" dans la figure), dans la fonction "ProcessTCPPacket", ce message H245 indiquant que la négociation H323 est maintenant achevée. L'envoi et la réception des flux audio peuvent alors débuter et on passe à l'étape 705. Sinon, on passe à l'étape 710. Pour l'ajout du destinataire RTP/RTCP, étape 705, si le message H323 reçu est OpenLogicalChannelAck , le transmetteur téléphonique Wifi considère que l'envoi et la réception des paquets RTP/UDP audio peuvent débuter. L'adresse IP et les ports RTP et RTCP du destinataire sont mémorisés. La fonction "ProcessTCPPacket" sort avec le code retour 0x11 pour indiquer le début de l'envoi et de la réception des paquets audio. La fonction principale "main" active alors les interruptions d'horloge timers avec une fréquence de 8000Hz soit une période de 125 micro- secondes et rentre dans la boucle de traitement commune aux flux audio et aux paquets IP. Puis on passe à l'étape 710. Au cours de l'étape 710, qui concerne l'envoi d'une réponse H323, lors de la négociation H323, chacun des messages H323 ou 1-1245 reçus par le téléphone Wifi fait l'objet d'une réponse respectant la norme H323 encodée au format ASN.1 PER. Puis on retourne à l'étape 615. Si l'étape 645 détermine que le paquet est de type RTP, au cours d'une étape 655, on teste le paquet RTP: la fonction "ProcessRx" teste s'il s'agit d'un paquet UDP, et ensuite elle vérifie que le port destination correspond bien au port RTP du téléphone Wifi. Si le paquet RTP reçu a bien, pour port source, le port RTP de l'expéditeur RTP/RTCP issu de la négociation H323, le traitement du paquet audio reçu peut commencer. Sinon, on retourne à l'étape 615. Si il s'agit du premier paquet audio, le programme calcule alors la taille des informations audio contenues dans le paquet, afin de dimensionner correctement la mémoire tampon buffer tournant de réception audio. Puis, au cours d'une étape 660, le flux audio reçu est encodé selon le codec G711 Mu-Law. Un décodage brut donnerait une série d'échantillons codés sur 16 bits, ce qui est incompatible avec la résolution du module PWM du microcontrôleur Microchip PIC18F452 limitée à 10 bits. Un algorithme spécifique de décodage G711 Mu-Law ulaw2linear8 a donc été développé pour restituer les échantillons sonores au format 8 bits. Puis, au cours d'une étape 665, étape d'écriture dans la mémoire tampon buffer tournant de réception, la mémoire tampon buffer tournant de réception est dimensionnée à deux fois la taille des paquets audio reçus. Ce doublement de la taille permet de compenser les décalages temporels dans la réception, ce qui assure un bon confort acoustique. Après décodage G711 Mu-Law, les échantillons 8 bits sont inscrits dans la mémoire tampon buffer de réception. La position d'écriture dans la mémoire tampon buffer est alternativement dans la première moitié ou la seconde moitié de la mémoire tampon buffer au fur et à mesure des paquets reçus. Ce mode alternatif permet d'éviter que l'on inscrive des échantillons dans la partie de la mémoire tampon buffer en cours de lecture par la routine d'interruption. Si l'étape 675 détermine que le paquet est de type HTTP, au cours d'une étape 670, étape d'envoi d'une réponse HTTP, la fonction "ProcessTCPPacket" évalue la chaîne GET reçue par le transmetteur audio et répond en envoyant une réponse HTTP suivie d'une page Web écrite en HTML. Si l'étape 645 détermine que le paquet n'est ni RTP, ni TCP, au cours d'une étape 650, étape d'envoi d'une réponse ARP, ICMP, si le paquet IP est de type ICMP, la fonction "ProcessRx" envoie une réponse à l'expéditeur en appelant la fonction "SendlCMPReply". Si le paquet est de type ARP (code LLCSNAP/PID 0x806), la fonction "ProcessRx" envoie une réponse en appelant la fonction "SendARPReply". Puis, on retourne à l'étape 615. Si l'étape 615 détermine qu'aucun paquet n'a été reçu, au cours d'une étape 620, on détermine si une session RTP est active. Si aucune session RTP n'est active, la fonction principale "main" reboucle à l'étape 615, en attente de réception d'un paquet. Si une session RTP est active, on effectue, au cours d'une étape 625, un traitement d'émission audio RTP/RTCP, la fonction principale "main" appelant ce traitement dans sa boucle infinie. Pour des raisons de performance, ce traitement s'opère en trois temps selon la position de l'index dans la mémoire tampon buffer tournant d'émission. Si l'index est nul, le paquet RTP d'émission est initialisé en appelant la fonction "PrepareToSendRTPPacket". Cette fonction paramètre les informations séquentielles et temporelles ("TimeStamps") permettant au récepteur de savoir comment ordonnancer les paquets reçus. Ensuite, au fur et à mesure de leur arrivée, les échantillons sonores sont convertis au format G711 Mu-Law en appelant la fonction "linear2ulaw8" et inscrits dans le paquet RTP d'émission. Puis, une fois que l'index d'émission atteint la taille du paquet RTP, le paquet RTP est envoyé vers le destinataire issu de la négociation H323. Puis, au cours d'une étape 630, on procède à l'encodage G711 au cours duquel les échantillons sonores sont encodés selon le codec G711 Mu-Law. Dans le mode de réalisation décrit, un encodage brut serait inapproprié car il se baserait sur des échantillons de 16 bits alors que le convertisseur analogique/numérique inclus dans le microcontrôleur Microchip PIC18F452 a une résolution limitée à 10 bits. Un algorithme spécifique d'encodage G711 Mu-Law "linear2ulaw8" a donc été développé pour encoder les échantillons sonores 8 bits au format G711 MULaw. Puis, au cours d'une étape 635, on envoie un paquet UDP/RTP, une fois la mémoire tampon buffer de transmission complétée, le paquet RTP étant alors envoyé au destinataire. Le numéro de séquence est incrémenté et l'index d'émission est réinitialisé. Puis, on retourne à l'étape 615. La figure 6B concerne les étapes effectuées en cas d'interruption d'horloge (limer"), étape 715. Cette interruption est activée par la fonction principale "main" lorsqu'une session H323 a abouti et qu'un destinataire RTP/RTCP est donc identifié. Le microcontrôleur transfère alors la main à la routine d'interruption "clock_isr" et revient au programme principal à l'issue de la routine d'interruption. Le microcontrôleur génère automatiquement l'interruption "TIMERO" dès que le compteur "TIMERO" s'annule. Il est donc nécessaire de réinitialiser ce compteur dans la routine d'interruption afin qu'une nouvelle interruption puisse être générée. Au cours d'une étape 720, on effectue la conversion analogique/numérique: outre l'initialisation du compteur "TIMERO", la fonction "clock_isr" récupère le résultat de la conversion analogique-numérique sur le port ANO. Cette conversion prend environ 20 microsecondes, ce qui est compatible avec la fréquence d'échantillonnage de 8000 Hz qui nécessite une mesure toutes les 125 micro-secondes. Puis, au cours d'une étape 725, on procède à l'écriture dans la mémoire tampon buffer tournant d'émission, une fois l'échantillonnage audio effectué, le résultat de la conversion étant inscrit dans la mémoire tampon buffer tournant d'émission et l'index du buffer d'émission étant incrémenté pour préparer la prochaine écriture. Au cours d'une étape 730 de lecture dans la mémoire tampon buffer tournant de réception, la routine d'interruption lit, mémorise, et efface l'emplacement de la mémoire tampon buffer de réception situé à l'index de lecture. Puis, au cours d'une étape 735 de conversion numérique/analogique PWM, la valeur lue dans la mémoire tampon buffer de réception est paramétrée dans l'interface "PulseWidthModulation" du microcontrôleur PIC18F452. Ainsi, une impulsion proportionnelle à la valeur paramétrée est générée, ce qui permet, après filtrage, une restitution sonore dont l'amplitude est proportionnelle à la valeur numérique mémorisée. Ensuite, l'index de lecture dans la mémoire tampon buffer tournant de réception est incrémenté et la routine d'interruption rend alors la main au programme principal. En variante, le programme permet d'appeler un correspondant et d'entrer en communication avec lui. REVENDICATIONS 1 - Transmetteur sans fil (100, 400), caractérisé en ce qu'il comporte: un capteur de sons (105, 405), - un émetteur à courte portée (130, 430) et - un circuit électronique (110, 410) comportant un unique circuit intégré consistant en un microcontrôleur reprogrammable (120, 420) adapté à mettre en oeuvre un standard de communication à courte portée pour transmettre des paquets de données organisées en transmission de flux de données standardisée à une borne d'accès à un réseau informatique, selon un protocole de communication sur ledit réseau informatique. 2 - Transmetteur selon la revendication 1, caractérisé en ce que le microcontrôleur reprogrammable (420) comporte une sortie de signaux sonores destinés à être émis par un transducteur électroacoustique (465) et en ce que le microcontrôleur reprogrammable est adapté à mettre en oeuvre un standard de communication à courte portée pour recevoir des paquets de données organisées en transmission de flux de données standardisée depuis ladite borne d'accès à un réseau informatique, selon un protocole de communication sur ledit réseau informatique. 3 Transmetteur selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) pilote une carte Wifi (130, 430) depuis une interface PCMCIA ou Personal Computer Memory Card International Association définie par l'Association Internationale des cartes mémoires pour ordinateur personnel (125, 425) ou depuis une carte Compact Flash. 4 Transmetteur selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole de flux temps-réels Internet RTSP, ou Real Time Streaming Protocol. Transmetteur selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole Temps-Réel Internet et Protocole de Contrôle Temps Réel Internet RTP/RTCP, ou Real Time Protocol/Real Time Control Protocol. 6 Transmetteur selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le capteur de sons (105, 405) est relié à une entrée analogique du microcontrôleur reprogrammable (120, 420). 7 Transmetteur selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole de résolution d'adresse ARP ou Address Resolution Protocol. 8 Transmetteur selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole Internet IP, ou Internet Protocol. 9 Transmetteur selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole universel de datagrammes Internet UDP, ou Universal Datagram Protocol. Transmetteur selon l'une quelconque des revendications 1 à 9, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole de contrôle de transmision Internet TCP, ou Transmission Control Protocol. 11 Transmetteur selon l'une quelconque des revendications 1 à 10, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente le protocole de voix sur IP de la norme H323. 12 Transmetteur selon l'une quelconque des revendications là 11, caractérisé en ce que le microcontrôleur reprogrammable (420) comporte une interface de sortie en modulation de largeur d'impulsion reliée à une filtre passe-bas (460) et met en oeuvre cette interface pour émettre un signal sonore. 13 Transmetteur selon l'une quelconque des revendications là 12, caractérisé en ce que le microcontrôleur reprogrammable (120, 420) implémente une adaptation d'un codec 16 bits pour un échantillonnage sur 8 bits.