Les problèmes d'écho et de latence audio sur BigBlueButton peuvent sembler similaires, mais ils nécessitent généralement des solutions différentes. Si les participants entendent leur propre voix en écho, suspectez un haut-parleur ouvert près d'un microphone ou un problème de connexion audio avec l'un d'eux. Si la parole arrive en retard, est hachée ou décalée d'un participant à l'autre, vérifiez la configuration du réseau et la connectivité WebRTC. Commencez par demander si le problème ne concerne qu'une seule personne ou tous les participants à la réunion.
Une distinction permet d'éviter des modifications inutiles : il est normal d'entendre votre propre voix pendant le test d'écho de BigBlueButton . Ce test permet de vérifier le son de votre microphone avant de rejoindre la réunion. Un écho persistant après avoir rejoint la réunion constitue un problème distinct.
L'écho est la répétition reconnaissable d'une voix. Le microphone d'une personne peut capter le son de ses haut-parleurs et le restituer lors de la réunion. Un léger délai peut donner à la voix renvoyée un son semblable à un écho, mais les fluctuations du réseau peuvent également engendrer un son haché ou en retard.
Le décalage audio signifie que la parole parvient aux auditeurs avec un retard perceptible, souvent accompagné de pauses, d'un son robotique ou de coupures. Ce délai peut affecter un seul participant en raison de sa connexion locale, ou plusieurs participants à cause d'un problème de serveur partagé ou de réseau. Le schéma est plus important que le terme utilisé pour le décrire.
| Ce que les gens remarquent | Zone à vérifier en premier |
|---|---|
| Une seule personne entend sa propre voix pendant le test d'union | Retour d'écho du test ou microphone et haut-parleur sélectionnés |
| Plusieurs personnes entendent deux fois la voix du même participant | Les haut-parleurs, le placement du microphone ou l'appareil audio de ce participant |
| Un participant entend tout le monde en retard ou de manière saccadée. | Chargement du Wi-Fi, du VPN, du navigateur ou de l'appareil du participant |
| De nombreux participants subissent un décalage simultanément. | Charge du chemin réseau partagé, du pare-feu, du relais TURN ou du serveur BigBlueButton |
Il s'agit du test de microphone prévu. Lorsque vous choisissez de vous connecter avec un microphone, BigBlueButton demande l'autorisation au navigateur et diffuse votre voix. Son guide de test actuel indique que le niveau sonore doit réagir lorsque vous parlez et que vous pouvez modifier le périphérique audio (microphone ou haut-parleur) dans la boîte de dialogue audio. Si la lecture du test est claire et que le niveau sonore varie, sélectionnez « Oui » pour vous connecter.
Si vous continuez à vous entendre après avoir rejoint la réunion, ou si d'autres personnes entendent un écho, vérifiez la connexion audio en direct plutôt que de considérer le test comme un échec. Pendant un appel, coupez brièvement votre micro. Si l'écho cesse, réactivez-le et éloignez le micro des haut-parleurs, baissez le volume des haut-parleurs ou utilisez un casque. Si le fait de couper le micro d'un participant en particulier élimine l'écho pour tout le monde, demandez-lui de vérifier sa configuration.
Utilisez un casque audio avec microphone près de votre bouche. Cela réduit le risque que les haut-parleurs de la pièce soient captés par le microphone. Baisser le volume des haut-parleurs ou augmenter la distance entre ceux-ci et le microphone peut aider, mais un casque audio est généralement la solution la plus fiable dans une chambre partagée.
Vérifiez qu'un seul microphone est actif. Il est possible que le microphone de l'ordinateur portable et celui de la webcam soient tous deux disponibles, et celui sélectionné peut être plus éloigné du haut-parleur que prévu. Dans les paramètres audio de BigBlueButton, choisissez explicitement le microphone et le haut-parleur souhaités. Si un écho apparaît après le changement de périphérique, quittez la session audio puis reconnectez-la afin que le test d'écho s'effectue avec la paire sélectionnée.
Dans une salle de réunion avec plusieurs personnes, évitez que plusieurs ordinateurs à proximité diffusent le son via des haut-parleurs ouverts. Utilisez une seule connexion audio avec un microphone adapté, ou demandez à chaque participant d'utiliser un casque et de couper son micro lorsqu'il ne parle pas. Un ordinateur portable non mis en sourdine peut créer un effet Larsen, même si votre propre appareil est correctement configuré.
Un test d'écho réussi indique que le navigateur a obtenu l'accès au microphone et a pu effectuer un test audio local. Cela ne garantit cependant pas une faible latence de la connexion Internet pendant toute la durée de la réunion. BigBlueButton transmet des flux multimédias en temps réel via WebRTC ; des restrictions réseau, une connexion Wi-Fi instable, des pertes de paquets ou un trafic réseau saturé peuvent entraîner des retards ou des interruptions audio.
Commencez par une comparaison simple. Demandez à un autre participant s'il perçoit le même décalage. Si une seule personne est concernée, essayez sa connexion filaire, désactivez temporairement son VPN, rapprochez-vous du point d'accès Wi-Fi ou changez de réseau. Suspendez les téléchargements et chargements importants, ainsi que les sauvegardes dans le cloud, pendant l'appel. Fermez les onglets ou applications gourmands en ressources si l'ordinateur est sollicité. Testez avec la caméra désactivée pendant quelques minutes ; si la qualité audio s'améliore, le problème peut venir de la bande passante ou de la puissance de traitement de l'appareil.
Si le décalage est identique pour tous les participants, changer le micro d'un seul ne suffira probablement pas à le résoudre. Notez à quel moment le décalage a commencé et s'il se produit lors de chaque réunion sur le même serveur. L'organisateur de la réunion doit demander à l'administrateur système de vérifier le serveur et le réseau.
Assurez-vous que votre navigateur dispose des autorisations d'accès au microphone pour le site BigBlueButton. Si l'autorisation a été refusée, modifiez-la dans les paramètres du navigateur, rechargez la réunion et rejoignez l'audio. Utilisez un navigateur à jour compatible avec le service BigBlueButton. L'utilisation d'une fenêtre de navigation privée peut s'avérer utile pour comparer les performances si une extension ou un paramètre du site mis en cache interfère, mais elle ne remplace pas la vérification de la sélection de votre appareil.
Dans la boîte de dialogue d'écho, parlez et observez l'indicateur de niveau audio. S'il ne bouge pas, sélectionnez un autre microphone et vérifiez le niveau d'entrée ou le commutateur de sourdine du système d'exploitation. Si le niveau bouge mais que vous n'entendez toujours pas le test, vérifiez le périphérique de sortie audio sélectionné et le volume du système. La documentation de BigBlueButton explique comment sélectionner les périphériques audio pendant le test et les modifier après la connexion ; lorsque le test n'est plus disponible, quittez le mode audio et reconnectez-vous.
Utilisez les commandes de votre navigateur et le panneau de configuration audio de votre système d'exploitation pour vérifier que les mêmes périphériques d'entrée et de sortie sont sélectionnés. N'augmentez pas excessivement le gain du microphone simplement pour faire bouger le vumètre ; un niveau d'entrée trop élevé peut capter le bruit ambiant et aggraver l'effet Larsen.
Demandez à l'administrateur d'enquêter lorsque plusieurs participants sont touchés, lorsque des utilisateurs sur différents réseaux rencontrent des problèmes similaires ou lorsque BigBlueButton signale une erreur de connexion WebRTC. La documentation de dépannage actuelle de BigBlueButton 4.0 décrit l'erreur 1007 : Échec de la négociation ICE, comme un échec de négociation d'un chemin média et mentionne la NAT, le blocage des ports UDP ou la nécessité d'un relais TURN sur les réseaux restrictifs comme causes possibles. WebRTC utilise ICE pour trouver un chemin de connexion fonctionnel ; un relais tel que TURN peut aider les clients qui ne peuvent pas établir de chemin média direct.
Pour un serveur auto-hébergé, l'administrateur doit comparer son pare-feu, sa configuration NAT et les adresses média annoncées avec la documentation de la version de BigBlueButton installée. Les recommandations actuelles concernant les pare-feu préconisent les ports TCP 80/443 et une plage de ports UDP pour la configuration documentée, mais les fournisseurs d'hébergement et les déploiements peuvent différer. Ne modifiez pas les règles de pare-feu sur un service géré ; communiquez au fournisseur le code d'erreur, l'heure de la réunion concernée et précisez si le problème affecte un seul réseau ou plusieurs.
La contention du processeur du serveur peut également affecter la diffusion multimédia en temps réel. Si tous les participants signalent un délai simultanément, l'administrateur doit vérifier la charge du serveur et l'état du service WebRTC/audio de BigBlueButton pendant l'incident. Un statut serveur normal après la réunion peut ne pas révéler une surcharge temporaire ; il est donc important d'inclure les horodatages et les détails permettant de reproduire le problème.
Quittez puis rejoignez la réunion audio, effectuez le test d'écho et vérifiez que le niveau du microphone réagit lorsque vous parlez. Une fois de retour, demandez à un autre participant de confirmer que votre voix est claire et sans écho. En cas de latence, comparez l'audio avec celui d'un autre participant et notez si la parole est désormais synchronisée et continue. Testez une modification à la fois afin d'identifier celle qui a résolu le problème.
L'interface de BigBlueButton et les informations de configuration réseau du serveur varient selon la version et le déploiement. Les pages de dépannage et de test de BigBlueButton 4.0 mentionnées sont indiquées comme « en développement » au 6 octobre 2026 ; les administrateurs doivent utiliser la documentation correspondant à leur version installée plutôt que de copier les paramètres d'une autre version.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
