Mesures Correctives pour les Décrochages Audio dans les DAW via l’Amélioration de la Latence DPC

Il existe diverses approches pour stabiliser le fonctionnement d’une DAW tout en maintenant le buffer ASIO de l’interface audio à un niveau bas et en prévenant les décrochages audio (interruptions sonores ou bruit).

Cette fois, nous nous concentrerons spécifiquement sur les « mesures correctives de la latence DPC », en expliquant celles-ci sur la base d’une expérience réelle.

Mon environnement de production est Cubase Pro 14, Windows 10, i5-8400, Rubix22, et GT1030 (à partir de 2025).

Qu’est-ce que la Latence DPC ?

DPC signifie « Deferred Procedure Call », et c’est l’un des mécanismes utilisés par Windows pour prioriser et exécuter efficacement le traitement de multiples tâches et pilotes de périphériques. En termes simples, c’est un mécanisme par lequel l’OS met temporairement en file d’attente les traitements qui peuvent être « différés » et les exécute une fois que les traitements de priorité plus élevée sont terminés.

Les signaux audio de la DAW, par nature, doivent être traités en continu à des intervalles de temps très courts. Cependant, si l’OS consacre plus de temps que prévu au traitement DPC d’autres pilotes de périphériques (tels que les adaptateurs réseau ou les périphériques USB), le traitement du pilote audio est différé et le transfert de données prend du retard. C’est un état de « latence DPC élevée », et cela provoque des phénomènes tels que les suivants :

• Interruptions sonores comme des pops ou des clics
• Bruit de clics
• Sauts de son (décrochages)
• Dans les cas graves, la DAW ou l’interface audio peut ne plus être reconnue

Ces problèmes ont un impact fatal et grave sur le fonctionnement stable d’une DAW, rendant les mesures correctives de la latence DPC importantes.

Vérifier la Latence DPC avec LatencyMon

Pour vérifier la latence DPC, vous utilisez une application appelée « LatencyMon ». LatencyMon vous permet de mesurer la latence DPC et ISR en temps réel et d’identifier les pilotes de périphériques qui causent une latence significative.

La méthode consiste à démarrer la mesure avec LatencyMon et à utiliser votre DAW comme d’habitude pendant au moins 5 minutes. Effectuez également la mesure dans l’« état d’inactivité de l’OS » sans lancer la DAW ni rien faire.

Après avoir terminé la mesure, vous procéderez aux mesures correctives pour les pilotes de périphériques individuels affichés dans l’onglet Drivers.

Native Instruments a publié des vidéos et des documents faciles à comprendre sur la série d’étapes et sur la manière de traiter les pilotes de périphériques spécifiques (avec sous-titres japonais), veuillez donc vous y référer :

Just a moment...

support.native-instruments.com

Indications pour une Latence DPC Acceptable

Une fois que vous pouvez saisir numériquement la latence DPC, il est naturel de ressentir le désir de la maintenir aussi basse que possible. Cependant, tomber dans un réglage excessif et négliger vos objectifs principaux de production musicale est contre-productif (cela s’applique à tous les réglages de personnalisation de DAW). Par conséquent, en comprenant à l’avance les valeurs de référence de la latence DPC, il devrait être possible de viser un environnement DAW modérément stable.

Plus précisément, d’après l’expérience, il semble raisonnable de considérer que c’est acceptable si les valeurs se situent dans les plages suivantes et qu’aucun bruit ou décrochage ne se produit pendant le fonctionnement normal de la DAW :

• Pilotes de périphériques individuels : 500 microsecondes ou moins
• Valeur de latence totale : 1 000 microsecondes ou moins

Dans mon environnement (Windows 10, i5-8400, Rubix22, GT1030), après la mise en œuvre de mesures correctives, la latence maximale pour les pilotes de périphériques individuels est d’environ 300-500 microsecondes, et le maximum total est d’environ 500 microsecondes. Avant la mise en œuvre de mesures correctives, il y avait des cas où la valeur totale atteignait environ 1 000 microsecondes, mais même alors, aucun bruit ni décrochage n’a été observé.

Si vous utilisez des réglages tels qu’un buffer ASIO de 64 samples ou moins, des décrochages audio peuvent se produire avec ces valeurs indicatives, mais avec des réglages de 256 samples ou plus, il est généralement peu probable que cela pose problème.

Incidemment, à 44,1 kHz, le temps acceptable pour 64 samples est d’environ 1 450 microsecondes, et pour 256 samples, il est d’environ 5 800 microsecondes.

Si les divers processus au sein de la DAW et de l’OS, y compris la latence DPC, sont achevés dans ce délai acceptable, le problème des décrochages audio ne se produira pas.

Exemple de Mesure Corrective Spécifique : Réglages de l’Adaptateur Réseau (NIC)

Dans mon environnement, la latence de « ndis.sys » était significative, dépassant fréquemment 800 microsecondes et parfois largement 1 000 microsecondes. L’adaptateur réseau intégré que j’utilise est le « Realtek PCIe GbE Family Controller ». J’ai ouvert les propriétés de l’adaptateur réseau dans le Gestionnaire de périphériques et effectué les réglages suivants :

• Désactiver la « Modération des Interruptions ».
• Désactiver l’Offload (traitement des sommes de contrôle, etc., par la NIC).

En conséquence, j’ai pu réduire la latence à moins de la moitié de la valeur initiale (maintenue en dessous d’environ 400 microsecondes maximum pendant l’utilisation de la DAW).

Désactiver la « Modération des Interruptions »

Dans ce cas particulier, la désactivation de la Modération des Interruptions a été particulièrement efficace. La « Modération des Interruptions » est un mécanisme par lequel, au lieu d’interrompre immédiatement le CPU chaque fois qu’un paquet de données arrive, il attend que plusieurs paquets s’accumulent ou qu’un certain temps s’écoule, puis notifie le CPU avec une seule interruption combinée.

Désactiver la Modération des Interruptions signifie que le traitement des paquets de données est effectué dès leur arrivée, ce qui pourrait sembler augmenter la charge du CPU à première vue. Cependant, avec les performances actuelles des CPU, cela ne représente qu’une marge d’erreur, et l’impact de la latence due à l’attente du traitement est significativement plus important, menant à de grandes améliorations comme dans ce cas (en fait, aucune modification de la charge du CPU ou de la consommation d’énergie n’a été observée).

Désactiver l’Offload (la NIC gère le traitement des sommes de contrôle, etc.)

Désactivez les éléments suivants :

• Offload de somme de contrôle IPv4
• Offload de somme de contrôle TCP (IPv4)
• Offload de somme de contrôle TCP (IPv6)
• Offload de somme de contrôle UDP (IPv4)
• Offload de somme de contrôle UDP (IPv6)

La désactivation de l’Offload a eu un léger effet, mais elle a éliminé les cas où Wdf01000.sys et CLASSPNP.sys causaient parfois une latence dépassant 1 000 microsecondes lorsque l’Offload était activé (un lien direct est inconnu).

À l’origine, l’offload du traitement des sommes de contrôle et autres vers la NIC devrait alléger la charge de traitement, mais en réalité, ce n’est pas toujours le cas, et cela cause parfois une latence DPC élevée. L’hypothèse pour la cause est que pour assurer l’intégrité des données IP, diverses verrous sont nécessaires au sein de l’OS, ce qui peut paradoxalement ralentir le traitement.

À propos d’autres réglages de la NIC

D’autres mesures correctives comprennent les suivantes, mais aucun changement n’a été observé dans mon cas même après les avoir réglées (une amélioration de la latence peut être observée selon l’environnement) :

• Désactiver Large Send Offload (la NIC gère la segmentation des paquets de données volumineux à envoyer).
• Désactiver Receive Side Scaling (RSS : traitement multi-cœur).
• Désactiver les réglages d’économie d’énergie.

Incidemment, la fonction d’économie d’énergie de la NIC s’active/désactive extrêmement rapidement, et il est considéré peu probable que cette fonction affecte la latence. Comme aucun impact n’a été observé dans mon environnement, je garde la fonction d’économie d’énergie activée pour des raisons opérationnelles.

Exemple de Mesure Corrective Spécifique : Réglages du Pilote Graphique

Un autre domaine qui a conduit à une amélioration significative a été les réglages du pilote graphique. Plus précisément, en désactivant la « Planification du GPU accélérée par le matériel » dans les réglages Windows, j’ai pu grandement améliorer la latence DPC. Initialement, une latence maximale de 700-1 000 microsecondes était mesurée, mais après les mesures correctives, les valeurs maximales soudaines sont d’environ 500 microsecondes, et pendant l’utilisation normale de la DAW, elle reste dans la limite d’environ 300 microsecondes maximum.

Comme j’utilise une ancienne carte graphique conçue comme la NVIDIA GT1030, cela ne peut pas être considéré comme une mesure corrective générale, mais je le partage car cela a été très efficace.

Ce réglage est activé par défaut dans Windows 11, il faut donc une raison considérable pour le désactiver intentionnellement. Dans ce cas, le déséquilibre des performances entre le CPU et le GPU (déficience des performances du GPU) pourrait avoir paradoxalement causé une charge ou des délais de traitement du côté du CPU. Alternativement, en raison de l’âge de la conception du GPU, il est concevable que le pilote ou l’OS ne fonctionne pas comme prévu.

En tout cas, puisqu’il y a eu une amélioration claire de la latence DPC mesurée, j’utilise « Planification du GPU accélérée par le matériel » désactivée dans mon environnement.

À propos de la « Planification du GPU accélérée par le matériel »

Cette fonctionnalité a été publiée dans Windows 10 en 2020. Comme son nom l’indique, elle décharge une grande partie de la planification du GPU du CPU vers un processeur de planification dédié basé sur le GPU. En faisant en sorte que la planification du GPU soit gérée par l’accélération matérielle, la charge du CPU (surplus de planification du GPU) est réduite, améliorant les performances et la latence du système dans certains processus.

Cependant, en réalité, les cas où aucun changement de performance n’est observé avec cette fonctionnalité sont fréquents. La raison serait que les programmeurs de développement avaient déjà trouvé des moyens efficaces (optimisations) pour gérer la planification traditionnelle du GPU et avaient presque atteint les limites de performance. On estime que l’objectif de Microsoft avec cette fonctionnalité n’était pas seulement l’amélioration des performances, mais la modernisation du système graphique et l’ouverture de la voie pour l’avenir.

Mesures Correctives pour ntoskrnl.sys

Si LatencyMon affiche une latence significative pour « ntoskrnl.sys », identifier le problème devient difficile. En effet, ntoskrnl.sys est le noyau central de l’OS Windows lui-même, et il est difficile de le lier à un pilote de périphérique spécifique comme « ce périphérique ».

Lorsque ntoskrnl.sys cause de la latence DPC, cela signifie que le noyau est en état d’attente ou que le traitement prend beaucoup de temps pour l’une des raisons suivantes :

• Traitement propre au noyau : Le traitement dans les parties fondamentales de l’OS (planification, gestion de la mémoire, gestion des processus, gestion des E/S, etc.) prend du temps.
• Traitement par procuration pour d’autres pilotes ou événements système : De nombreux pilotes interagissent avec le matériel et demandent des services OS via ntoskrnl.sys. Par conséquent, un traitement inefficace ou un temps d’attente causé par d’autres pilotes peut apparaître comme si ntoskrnl.sys était le coupable.
• Changements d’état spécifiques à l’échelle du système : Le traitement d’événements au niveau du système tels que les transitions d’état d’alimentation, les changements de fréquence du CPU, ou les SMIs (interruptions de très haute priorité gérées par le BIOS) est mesuré comme une activité de ntoskrnl.sys, ce qui les fait apparaître comme de la latence.

À partir de ces points, si la latence DPC de ntoskrnl.sys est élevée, la première chose à aborder est les réglages liés à l’alimentation (réglages d’économie d’énergie). Examinez les réglages d’économie d’énergie pour le CPU et les divers pilotes, et mesurez les changements de latence tout en désactivant individuellement les fonctions d’économie d’énergie.

Si vous avez besoin d’utiliser un petit buffer ASIO, désactiver les C-states dans le BIOS pour améliorer les performances ou définir le profil de gestion de l’alimentation de l’OS sur « Hautes performances » sont également efficaces.

Néanmoins, comme mentionné ci-dessus, identifier la cause de la latence de ntoskrnl.sys est difficile, il est donc recommandé de viser un niveau de latence modéré basé sur des indications réalistes et d’être satisfait si cela reste dans cette plage. En fait, dans mon cas, la latence maximale de ntoskrnl.sys après les mesures correctives pour les pilotes réseau et graphique n’a pas dépassé significativement 500 microsecondes pendant le travail normal, j’ai donc déterminé que d’autres mesures correctives ne valaient pas le coût en temps.

Mesures Correctives de la Latence DPC ~ Conclusion

Concernant les mesures correctives pour la latence DPC des DAW, vous pouvez trouver diverses informations détaillées en ligne, en commençant par comment utiliser LatencyMon. Par conséquent, dans cet article, je me suis concentré sur la présentation de cas spécifiques dans mon environnement de production. J’espère que les informations sur la résolution effective des problèmes de latence DPC vous seront utiles pour améliorer votre environnement.