Comprendre les chiffres de latence
- La latence audio temps réel ne peut physiquement pas être nulle — il y a toujours un minimum de 15-25 ms incompressibles.
- Le chiffre dans Mes Studios (ex. "~26 ms") = ta contribution one-way vers le serveur. Le chiffre sur la tranche d'un musicien dans le studio = la vraie latence note→oreille entre vous deux.
- Le seuil ~30 ms est la limite pratique de la perception synchrone (« comme dans la même pièce »). Au-dessus, l'oreille commence à percevoir un décalage.
Pourquoi je vois "26 ms" et pas "0 ms" ?
Parce que la latence c'est de la physique, pas du logiciel. Entre le moment où ta corde de guitare vibre et celui où le son sort du casque de ton pote, le signal traverse plusieurs étapes — chacune avec son temps de traitement incompressible.
Voici les 5 étapes audio (côté ton ordi) qui s'ajoutent à la latence réseau :
À ces ~20 ms s'ajoute le réseau : le temps que tes paquets audio mettent à atteindre le serveur Jamodio le plus proche. Sur une connexion résidentielle en Île-de-France vers nos serveurs européens, c'est typiquement 2-3 ms one-way (chiffre mesuré, pas estimé).
Total affiché ≈ 25 ms. C'est l'ordre de grandeur que tu vois dans Mes Studios, et c'est déjà très proche de la limite physique théorique pour une connexion résidentielle.
"Mes Studios" vs. dans le studio — ce ne sont pas les mêmes chiffres
Jamodio affiche deux chiffres de latence à des endroits différents. Ils mesurent deux choses sémantiquement distinctes.
RTT, aller simple, note→oreille : 3 chiffres à ne pas confondre
Avant tout, fixons le vocabulaire — c'est la source n°1 de confusion, y compris quand tu compares Jamodio à d'autres outils :
| Terme | Ce que ça mesure | Trajet | Exemple |
|---|---|---|---|
| RTT (aller-retour) | Le temps qu'un paquet met à aller au serveur et revenir | toi → serveur → toi | ~6 ms |
| Aller simple (one-way) | RTT ÷ 2 | toi → serveur | ~3 ms |
| Note→oreille | De la note jouée par un musicien jusqu'à ton oreille (chaîne audio des 2 côtés incluse) | lui → serveur → toi | ~35-45 ms |
~25 ms green
Affiché avant d'entrer dans un studio, sur chaque carte. C'est ta contribution one-way vers nos serveurs + ta chaîne audio locale.
ton réseau + ton audio
(estimation pré-session)
Utilité : choisir le serveur le plus proche / vérifier que ta connexion est viable avant de t'engager dans une session.
~35 ms yellow
Affiché pendant la session, sur la tranche de mixer de chaque musicien. C'est la vraie latence note→oreille entre lui et toi.
son audio + son réseau + relai +
ton réseau + ton jitter buffer + ton audio
Utilité : comprendre si tu es en phase avec ce musicien précis. Survole le badge pour voir la décomposition.
Concrètement, voici à quoi ressemblent ces deux chiffres dans l'app :
vers le serveur (ici ~26 ms)
en bas de la tranche (ici 30 ms)
Survole le badge d'une tranche en session pour voir sa décomposition. Sur ta propre tranche, il détaille le sortant (ce que les autres entendent quand tu joues, note→oreille) et ton monitoring local (ce que toi tu entends dans ton casque) :
Donc si dans Mes Studios tu vois "26 ms" et que dans le studio le badge de ton pote affiche "37 ms", ce n'est pas une erreur. Les deux mesurent des choses différentes. La règle d'inégalité : la note→oreille (badge musicien) est toujours supérieure à ta contribution seule (badge Mes Studios), parce qu'elle additionne sa chaîne ET la tienne.
Ce que chaque chiffre compte (et ce qu'il ne compte pas)
Les deux chiffres parcourent la même liste d'étapes. La différence ne tient qu'à deux étapes :
| Étape du trajet | note→oreille | badge Mes Studios |
|---|---|---|
| Capture micro | ||
| Encodage | ||
| Carte audio (entrée) | ||
| Réseau aller (vers le serveur) | ||
| Relai serveur | ||
| Réseau retour (du serveur vers le partenaire) | ||
| Buffer de réception (jitter) | ||
| Décodage | ||
| Sortie audio | ||
| Casque |
Surprise : le badge Mes Studios inclut bien ton décodage, ton buffer et ton casque — il modélise toute ta pile audio, entrée et sortie. La seule chose qu'il laisse de côté, c'est le relai serveur + le trajet réseau de retour, celui qui dépend de l'endroit où se trouve ton partenaire.
Et si on est 3 musiciens ou plus ?
Chaque musicien du studio a SA propre tranche avec SON propre badge. Le calcul est refait indépendamment pour chacun, à partir de SA distance réseau vers nos serveurs + la tienne. Tu ne vois donc pas un chiffre moyen : tu vois la vraie latence avec chaque musicien individuellement.
Exemple concret — toi à Paris, en session à 3 :
| Musicien | Sa position | Son badge dans ta mixette | Verdict |
|---|---|---|---|
| Pierre | Paris | ~28 ms | green |
| Paul | Paris | ~28 ms | green |
| Jacques | Toulouse | ~45 ms | orange |
Conséquence pratique : tu sais instantanément avec qui tu peux groover et avec qui il faudra compenser. Si Jacques décroche sur les morceaux rapides, c'est sa latence — pas son jeu.
À noter : avec un bon setup (carte audio + Ethernet, proche du serveur), deux musiciens parisiens atteignent le green (~28 ms, sous 30). Le plancher physique note→oreille en mode agent est d'environ 27 ms (chaîne audio des deux ordinateurs additionnée) : le vert est donc atteignable, mais sans grande marge — un setup dégradé (micro/HP intégrés, WiFi) repasse vite en yellow voire orange.
Constantes vs mesures réelles : qu'est-ce qui change en live ?
Tu pourrais penser que les chiffres affichés sont tous calculés en temps réel. La réalité est plus nuancée :
| Composant | Comment c'est obtenu | Varie en live ? |
|---|---|---|
| Réseau (one-way) | Mesuré en continu via des pings WebSocket vers nos serveurs, médiane glissante sur les derniers échantillons. | Oui, mis à jour toutes les 1,5 s. |
| Jitter buffer (agent) | Lu en direct depuis l'agent natif : la cible adaptative ajustée en temps réel selon la qualité du flux reçu. | Oui, mis à jour à 1 Hz. |
| Sortie audio (browser) | Lu en direct via AudioContext.outputLatency de ton navigateur. |
Oui, valeur réelle. |
| Capture micro | Estimation conservatrice basée sur le mode (agent ou browser). | Constante. |
| Encodage / décodage Opus | Estimation : Opus en 20 ms frame = ~2.5 ms encode + ~2.5 ms decode. | Constante. |
| Hardware (USB/TB) | Estimation : 2 ms typique pour USB 2.0 / Thunderbolt. | Constante. |
Les 3 valeurs marquées "constante" sont des estimations pessimistes calibrées sur les setups les plus courants. Le réel peut varier de ±5 ms autour du chiffre affiché selon ta carte audio précise. Mais les 3 valeurs dynamiques sont, elles, mesurées en live — c'est elles qui expliquent pourquoi ton badge bouge quand ta connexion bouge.
Pour aller plus loin — pourquoi ne pas tout mesurer en live ?
Mesurer la capture et le hardware en temps réel demanderait soit une boucle de calibration au démarrage (= friction utilisateur), soit un appel à l'API RTCRtpReceiver.getStats() toutes les 5 s. Cette dernière option ajoute un cycle d'appel asynchrone à la pipeline audio temps réel — ce qu'on refuse par principe : aucun nouveau process runtime ne doit toucher le chemin audio.
Le compromis retenu : constantes pessimistes pour ce qui est ~stable (capture/opus/hw), mesures live pour ce qui bouge vraiment (réseau, jitter buffer, sortie). Cette honnêteté affichée vaut mieux qu'une fausse précision.
Wi-Fi vs Ethernet : le mythe à dégonfler
Beaucoup de musiciens pensent que le Wi-Fi ajoute de la latence. C'est partiellement faux :
- Le Wi-Fi n'augmente pas la latence moyenne dans un environnement sain (~1 ms additionnel typique vs Ethernet).
- Mais le Wi-Fi augmente énormément le jitter — c'est-à-dire la variation de la latence d'un paquet à l'autre.
- Conséquence : le jitter buffer adaptatif côté réception grimpe automatiquement (de 10 ms à 30+ ms) pour absorber les variations, et c'est cette inflation qui se voit sur le badge.
En clair : en Wi-Fi de bonne qualité, ton badge peut très bien afficher la même valeur qu'en Ethernet. Mais dès qu'un voisin lance Netflix ou que ton point d'accès est saturé, le badge grimpe en quelques secondes — et tu commences à entendre des crachotements.
Pour le détail, voir l'article Ethernet vs Wi-Fi.
Mode agent vs mode navigateur : pourquoi l'écart de 40 ms ?
Jamodio fonctionne dans deux modes :
| Mode | Capture | Opus | Jitter | Sortie | Total audio |
|---|---|---|---|---|---|
| Agent natif (macOS / Windows) | 1-3 ms | 3-7 ms | 8-15 ms | 1-3 ms | ~15-25 ms |
| Navigateur seul | 20-30 ms | 8-15 ms | 15-30 ms | 4-8 ms | ~55-70 ms |
Le navigateur ajoute 30 à 50 ms incompressibles par rapport à l'agent natif. Ce n'est pas un défaut de Jamodio — c'est une limite physique du navigateur :
- Le navigateur n'expose pas les buffers audio en dessous d'une certaine taille minimale, et son ordonnanceur WebAudio empile derrière.
- La stack WebRTC du navigateur utilise un jitter buffer interne configuré pour la voix téléphonique (cible élevée par défaut) — pas pour la musique.
- L'encodage Opus passe par la stack WebRTC qui ajoute son propre pacing.
C'est pour ça que Jamodio fournit un agent natif téléchargeable. Il contourne complètement la stack du navigateur et accède directement aux APIs audio bas niveau du système. Gain : plusieurs dizaines de ms qui font passer une session de "frustrante" à "agréable".
Sur Windows : pourquoi ASIO change tout
Si tu es sur Windows, il y a un détail technique à comprendre — il n'est pas spécifique à Jamodio, il s'applique à tous les outils de jam en ligne (JackTrip, FarPlay, JamKazam, Jamulus…). Windows propose deux chemins audio très différents :
| Pile audio | Quand elle est utilisée | Latence buffer | Qui en bénéficie |
|---|---|---|---|
| WASAPI Shared (par défaut Windows) |
Toutes les apps grand public — Chrome, Spotify, Zoom, Discord. Le sound engine Windows mixe les sorties de toutes les apps. | ~10 ms plancher | Carte son intégrée, jack onboard, HDMI, USB sans driver ASIO. |
| ASIO (driver fabricant) |
Logiciels musicaux pros — Cubase, Ableton, Reaper, FL Studio… et l'agent Jamodio quand un driver ASIO est installé. | ~2-3 ms | Cartes audio externes USB / Thunderbolt (Focusrite, MOTU, Behringer, Steinberg, RME…) avec leur driver officiel. |
La différence vient du sound engine Windows. En mode WASAPI Shared (le défaut), Windows mixe en interne avec un buffer fixe de 480 samples (= 10 ms à 48 kHz), impossible à descendre plus bas. C'est une limitation de l'OS, pas un choix d'éditeur. ASIO contourne complètement ce mixeur en parlant directement au matériel via le driver fabricant.
Tous les concurrents Jamodio recommandent ASIO sur Windows : c'est la recette standard pour la jam en ligne. La bonne nouvelle : ça ne demande pas un gros budget — une Focusrite Scarlett Solo (~110 €), une Behringer UMC22 (~50 €) ou une Steinberg UR22C (~150 €) suffisent largement, drivers ASIO inclus côté constructeur.
Pour la procédure d'installation détaillée des drivers ASIO (avec captures), voir ASIO sur Windows.
Le seuil 30 ms — pourquoi cette valeur ?
Tu as peut-être remarqué que les badges Jamodio passent du vert au jaune à 30 ms. Ce n'est pas arbitraire : la recherche sur le jeu en réseau situe la zone de synchronisation serrée autour de 25-30 ms one-way, et montre qu'on joue encore très bien jusqu'à ~40 ms en compensant légèrement (on ralentit imperceptiblement). On retient 30 ms comme limite du vert : la borne haute de la zone « comme dans la même pièce », réellement atteignable avec un bon setup.
Les seuils Jamodio (< 30 · 30-40 · ≥ 40) :
- < 30 ms = "comme dans la même pièce". Le cerveau ne perçoit pas le décalage, le groove est intact.
- 30-40 ms = jouable, mais le musicien expérimenté commence à compenser instinctivement (ralentit légèrement). Bons résultats sur les morceaux à tempo modéré.
- ≥ 40 ms = décalage perceptible. Sur des morceaux rapides ou rythmés (funk, métal), ça devient gênant. Sur des ballades, ça reste praticable.
La couleur du badge suit ces seuils — un coup d'œil suffit. Exemple d'un badge dans la zone à corriger :
Pour aller plus loin — la latence dans une vraie pièce
Tu pourrais te dire : "OK 25 ms en ligne, mais dans une vraie pièce on est à 0 ms, non ?". Non. Le son voyage à ~340 m/s dans l'air. Entre deux musiciens à 3 mètres l'un de l'autre = ~9 ms de latence acoustique naturelle. Sur une scène de concert avec un bassiste à 10 m du batteur = ~30 ms. Les musiciens compensent ça depuis toujours.
Jamodio à 30 ms one-way ≈ jouer avec quelqu'un à ~10 mètres dans une pièce. C'est complètement praticable. C'est même la norme dans 90% des contextes de scène.
Pour aller plus loin
Maintenant que tu comprends les chiffres, les trois articles suivants te donnent les leviers concrets pour optimiser ta latence :