Latence audio : mesurer le délai du microphone et des haut-parleurs

Résumé (TL;DR)

Enregistrer une prise de guitare acoustique à travers ma vieille interface USB atterrissait autour de 35 ms de latence aller-retour dans les écouteurs de monitoring — assez pour que toute phrase rythmique donne l’impression de patauger dans du sable mouillé. Passer à une MOTU M2 avec un pilote ASIO correctement configuré a ramené cela dans la plage de 5 ms, et la même prise est immédiatement passée d’« injouable » à « naturelle ». Le phénomène n’est pas un bug ; c’est une réalité physique mesurable appelée latence aller-retour (RTT). La RTT est la somme de cinq étapes : le signal du microphone remplissant un buffer d’entrée, le logiciel hôte traitant ce buffer, le signal traité remplissant un buffer de sortie, le DAC le reconvertissant en analogique, et le son final se propageant à travers l’air jusqu’à votre oreille (environ 1 ms pour chaque 34 cm). La partie ajustable vit principalement dans la taille du buffer et le modèle de pilote ; ASIO, WASAPI Exclusive, Core Audio et JACK ont chacun des minimums typiques et des limites de plateforme différentes. Ce guide explique comment ces composants s’additionnent, pourquoi le compromis taux d’échantillonnage/taille de buffer n’est pas aussi intuitif qu’il paraît, et comment mesurer la latence réelle de bout en bout avec un câble en boucle, un signal de test et un éditeur audio — plutôt que de faire confiance aux revendications marketing de « 1 ms ».

Contexte et concepts

Entre un microphone et un haut-parleur, un ordinateur fait plus que la plupart des gens ne le réalisent. Un ADC échantillonne le signal du microphone à un taux d’échantillonnage choisi (couramment 48 kHz) et collecte les échantillons dans un buffer d’entrée. Une fois que le buffer se remplit — disons, 128 échantillons à 48 kHz, environ 2,67 ms d’audio — le pilote le remet à l’application.

L’application (un DAW, un client de communication, un navigateur) traite le buffer, applique des effets ou encode pour la transmission réseau, et écrit le résultat dans un buffer de sortie. Quand le buffer de sortie se remplit, le DAC le convertit en un signal analogique qui quitte la sortie casque ou ligne.

Puis il y a le monde à l’extérieur de l’ordinateur. Le son voyage à environ 343 m/s à température ambiante, ce qui signifie environ 1 ms par 34 cm. Les écouteurs n’ajoutent essentiellement rien de cela ; une enceinte de monitoring à travers la pièce ajoute quelques millisecondes par-dessus tout le reste. Une paire de moniteurs à 1,7 m de distance d’assise contribue environ 5 ms de pure propagation — invisible sur la fiche technique mais présent dans vos oreilles.

Donc latence aller-retour = buffer d’entrée + traitement + buffer de sortie + DAC + propagation. Avec le taux d’échantillonnage fixé, des buffers plus petits réduisent la latence mais augmentent la charge CPU, parce que le thread audio doit se réveiller plus souvent. Si la taille du buffer est spécifiée en échantillons plutôt qu’en temps, augmenter le taux d’échantillonnage raccourcit le même buffer « N échantillons » en millisecondes, mais des taux d’échantillonnage plus élevés augmentent aussi le débit et stressent différemment les pilotes, donc ce n’est pas un moyen gratuit de réduire le délai.

Le modèle de pilote se trouve entre l’application et le matériel audio et a ses propres caractéristiques de latence. Sur Windows, les chemins classiques MME et DirectSound ajoutent une mise en tampon substantielle pour la compatibilité ; WASAPI Shared est plus bas mais encore médiatisé par le mixeur ; WASAPI Exclusive et ASIO contournent une grande partie de cet overhead. ASIO4ALL est un wrapper ASIO générique qui aide quand un pilote ASIO fabricant n’est pas disponible, mais ce n’est pas un substitut pour un vrai pilote ASIO fabricant — la RTT mesurée sur la même Focusrite Scarlett 2i2 3e génération atterrit typiquement significativement plus bas avec le pilote officiel qu’avec ASIO4ALL par-dessus WASAPI. Sur macOS, Core Audio est déjà ajusté pour une faible latence comme valeur par défaut de la plateforme. Sur Linux, les piles JACK et PipeWire peuvent atteindre une très faible latence une fois configurées, mais elles nécessitent un ordonnancement kernel temps-réel pour être cohérentes.

Comparaison et données

Critère	ASIO	WASAPI Exclusive	Core Audio	JACK
Plateforme	Principalement Windows	Windows uniquement	macOS uniquement	Centré Linux, portages multiplateformes existent
Latence la plus basse typique	Très basse, couramment dans la plage des quelques millisecondes	Basse quand utilisé en mode exclusif	Basse et stable dans la plage des quelques millisecondes	Très basse quand bien configuré, avec plus de complexité de setup
Modèle de partage	Dépend du pilote (typiquement exclusif)	Partagé ou exclusif ; exclusif est à plus faible latence	Le mode partagé bien ajusté est par défaut	Basé sur matrice de routage, multi-client

Les nombres exacts en millisecondes dépendent fortement du matériel, du pilote et de la version de l’OS, donc plutôt que de faire confiance à la ligne « latence de 1 ms » sur une page produit, mesurez votre propre système une fois pour établir une ligne de base. Les interfaces abordables comme la MOTU M2 et la Focusrite Scarlett 2i2 3e gén. peuvent atteindre un aller-retour à un seul chiffre en millisecondes quand associées à un pilote ASIO ou Core Audio approprié, mais le même matériel sur un chemin WASAPI en mode partagé Windows ou enveloppé à travers ASIO4ALL se comporte typiquement notablement pire. Votre vraie RTT est le résultat joint de trois variables — interface, pilote, taille de buffer — et supposer l’une d’entre elles en isolation est rarement précis.

Scénarios concrets

Scénario 1 — Performance live et monitoring in-ear. Un chanteur écoutant sa propre voix à travers des moniteurs in-ear ressentira un délai de seulement quelques millisecondes comme un problème de timing. La cible ici est une RTT sous 10 ms, ce qui nécessite généralement des tailles de buffer faibles, un pilote à faible latence (ASIO sur Windows, Core Audio sur macOS) et — où possible — le monitoring direct matériel de l’interface, qui contourne entièrement le chemin logiciel pour le signal de monitoring. Le bouton de monitoring en façade de la MOTU M2 résout cela en un tour, et le commutateur « Direct » de la Scarlett 2i2 3e gén. fait de même.

Scénario 2 — Enregistrement de podcast. À moins que plusieurs hôtes ne se monitorent mutuellement en direct, 50 à 100 ms de RTT conviennent généralement pendant la session d’enregistrement. La post-production aligne les pistes de toute façon, et un buffer plus grand améliore la marge CPU, ce qui à son tour réduit le risque de coupures dans un long enregistrement. Optimiser pour la plus faible latence ici nuit souvent plutôt que d’aider.

Scénario 3 — Visioconférence. Les appels WebRTC basés sur navigateur opèrent typiquement dans une plage d’environ 100 à 200 ms de bout en bout à cause du réseau, de l’encodage et du buffering de jitter par-dessus la latence audio locale. Cela se trouve près de la frontière où les échanges conversationnels se sentent naturels ; ajouter des écouteurs Bluetooth avec un codec plus ancien peut pousser cela au-delà de ce seuil, c’est pourquoi les participants commencent à se couper la parole.

Scénario 4 — Collaboration musicale en ligne. Tenter de jouer de la musique synchronisée avec un partenaire distant sur Internet est le bout impitoyable de ce spectre. Au-delà d’environ 25 à 30 ms de délai aller, maintenir un tempo stable devient difficile, et l’internet domestique typique plus le logiciel audio grand public atterrissent régulièrement bien au-dessus. Des plateformes de collaboration dédiées à faible latence existent spécifiquement pour raser chaque milliseconde possible, et même alors elles nécessitent généralement un ethernet filaire, un réglage soigneux du pilote et une proximité physique sur le backbone internet. Reconnaître qu’une pile d’appel vidéo grand public est le mauvais outil pour ce travail est généralement la première étape.

Idées fausses courantes

« L’audio Bluetooth est toujours à haute latence. » Le streaming A2DP classique ajoute un délai significatif. Mais les codecs plus récents LE Audio (LC3) et aptX Low Latency réduisent cela considérablement, ce qui est un changement de catégorie en performance ressentie. Deux écouteurs qui disent tous deux « Bluetooth » peuvent différer dramatiquement selon le codec qu’ils et la source prennent en charge. Pour monitorer une session d’enregistrement cependant, le filaire reste le choix plus sûr.

« L’audio USB est toujours meilleur qu’analogique. » L’audio USB bat l’analogique intégré quand l’interface a un bon DAC, des préamplis propres et des pilotes stables. Les DAC USB bon marché peuvent en fait être pires à cause de la gigue, du bruit et des problèmes de pilote. « USB » seul n’implique pas la qualité ; le choix des composants oui.

« Un taux d’échantillonnage de 192 kHz est à plus faible latence. » Contre-intuitif mais important : si le buffer est spécifié en temps (ms), augmenter le taux d’échantillonnage ne réduit pas la latence physique. Seulement quand le buffer est fixé en échantillons un taux d’échantillonnage plus élevé signifie moins de millisecondes par buffer — au coût de plus de données par seconde, plus de CPU et plus de stress pilote. La faible latence vient principalement de buffers plus petits et d’un meilleur modèle de pilote, pas d’un taux d’échantillonnage plus élevé.

« Le monitoring logiciel et matériel se sentent pareils. » Ce n’est pas le cas. Le monitoring logiciel route le signal du microphone à travers le chemin DAW — buffer d’entrée, traitement des plugins, buffer de sortie — et accumule la RTT en chemin. Le monitoring matériel sur une interface audio envoie le signal mic directement à la sortie casque à l’intérieur de l’interface, contournant entièrement l’ordinateur pour le chemin de monitoring. L’interprète s’entend avec une latence effectivement nulle, tandis que l’ordinateur enregistre encore la piste pour production ultérieure. Beaucoup de setups confondent les deux et blâment la taille du buffer pour un délai que le monitoring matériel éliminerait en un changement de paramètre.

Liste de vérification

1. Définissez la cible RTT pour votre cas d’usage. Performance live : sous 10 ms ; enregistrement : 50 à 100 ms convient ; conférence : 100 à 200 ms est réaliste.
2. Choisissez le modèle de pilote. Sur Windows, ASIO ou WASAPI Exclusive ; sur macOS, Core Audio ; sur Linux, JACK ou PipeWire. Les piles en mode partagé par défaut (MME, WASAPI partagé par défaut) ont généralement la latence la plus élevée.
3. Baissez la taille du buffer incrémentalement jusqu’à juste avant que les coupures ne commencent. C’est le plancher pratique de votre système.
4. Faites une mesure en boucle. Connectez la sortie de l’interface à son entrée avec un câble, jouez un signal de test, et lisez le délai depuis la forme d’onde capturée dans un éditeur audio.
5. Faites correspondre le taux d’échantillonnage au besoin du projet. 48 kHz est typique pour le travail vidéo ; 44,1/48 kHz pour la musique. Montez au-dessus seulement avec une raison spécifique.
6. Utilisez le chemin de monitoring judicieusement. Où possible, utilisez la fonctionnalité de monitoring direct de l’interface pour les oreilles de l’interprète, ce qui rend la RTT de monitoring effectivement nulle même si le chemin d’enregistrement a plusieurs millisecondes de latence.

Outil associé

L’outil de latence audio Patrache Studio estime la latence aller-retour dans le navigateur, ce qui rend facile d’obtenir une lecture approximative sans acheter de matériel. Pour l’image plus large de la « latence d’entrée » dans un contexte gaming, voyez NKRO et latence d’entrée pour le gaming. Si vous ajustez une configuration d’appel vidéo où le délai audio affecte la synchronisation A/V, associez ce guide à Diagnostics webcam : taux de rafraîchissement, résolution et éclairage pour comprendre la latence côté caméra qui s’empile sur l’audio.

Références

• Documentation Steinberg ASIO — https://www.steinberg.net/en/company/technologies/asio.html
• Microsoft Learn, audio Windows à faible latence (WASAPI) — https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
• Bluetooth SIG, spécifications LE Audio — https://www.bluetooth.com/specifications/specs/le-audio