Pourquoi le son se coupe-t-il alors que l'utilisation du processeur est faible ? — Raisonner à partir du tampon et de l'échéance

Vous écoutez de la musique, et de temps en temps le son se coupe avec un « clic ». Le Gestionnaire des tâches affiche une utilisation du processeur d’environ 10 %, et pourtant seul le son reste instable. Dans ce cas, pourquoi le son se coupe-t-il alors que le processeur a de la marge ?

Même lorsque l’utilisation du processeur est faible, le son peut se couper si le réapprovisionnement des données audio suivantes ne respecte pas son échéance. En effet, les données suivantes doivent être transmises pendant que le son restant dans le tampon est lu. Un réapprovisionnement retardé par des attentes sur des données ou des verrous, par des DPC/ISR sur le processeur logique nécessaire ou par d’autres causes survient même sans que le processeur soit utilisé à plein dans son ensemble. Exclusive-Mode Streams, CPU Analysis

Cependant, le « clic » entendu ne suffit pas à affirmer qu’il s’agit d’une sous-alimentation (underrun). La source audio, l’application, les effets audio, le périphérique de sortie et d’autres éléments produisent eux aussi des symptômes similaires. On commence par comparer avec la même source audio en changeant les conditions une par une puis en les rétablissant ; si cela ne suffit toujours pas à cerner la cause, on enregistre ce qui se passe avant et après la coupure. Fix distorted or crackling audio in Windows

Cet article traite de cette question et de celles qui en découlent : « Suffit-il d’agrandir le tampon ? » et « Que faut-il comparer et enregistrer pour cerner la cause ? ». Il ne prétend pas établir la cause d’une panne particulière à partir de la seule utilisation du processeur ou du son entendu.

Le périmètre est principalement la sortie audio sous Windows 11. Les sorties intégrées, filaires, USB, Bluetooth et autres servent de points de comparaison ; pour les logiciels de production musicale (DAW), l’article traite aussi des comparaisons lorsque l’application ou le pilote propose un réglage de tampon. La conception de l’ensemble de la chaîne d’enregistrement audio et le diagnostic des communications sans fil propres à chaque périphérique ne sont pas couverts.

L’explication prend le mode partagé comme exemple de base. Le chemin réel, la taille des tampons et la période de traitement varient selon l’application, l’API, le pilote et le périphérique, et il n’existe pas non plus d’écran de réglage du tampon commun à toutes les applications. Low Latency Audio

L’utilisation du processeur, les 10 millisecondes restantes, les instants de réapprovisionnement et les autres valeurs présentées ici sont des hypothèses destinées à l’explication. Il ne s’agit pas du compte rendu de mesures sur un PC donné où la coupure aurait été reproduite ou une amélioration constatée. Les opérations de la seconde moitié sont des procédures de vérification à mener dans votre propre environnement.

Le mécanisme se lit dans l’ordre à partir de la section suivante, « Tampon de lecture audio ». Les opérations pour investiguer les coupures se trouvent dans « Comparer les conditions où la coupure se reproduit » et « Enregistrer la coupure avec WPR ».

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (5 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

Tampon de lecture audio

Il ne suffit pas d’enregistrer un fichier musical pour que les haut-parleurs produisent du son. L’application prépare les données audio et les fait parvenir au périphérique de sortie en passant par Windows et le pilote. Le tampon de lecture audio est la zone qui retient temporairement les données à lire ensuite. Pendant que le périphérique lit les données en cours, le côté qui alimente prépare les données suivantes et réapprovisionne le tampon. Rendering a Stream

flowchart TB
    accTitle: Accumuler un peu de son à l'avance, puis le lire
    accDescr: Flux dans lequel les données audio préparées réapprovisionnent le tampon, et où les données suivantes sont préparées pendant que la lecture avance côté périphérique.
    A["Préparer le son suivant"] --> B["Réapprovisionner le tampon"]
    B --> C["Lire le son accumulé"]
    C -.->|"avant épuisement"| A

Figure 1 : Pour que la lecture continue, le réapprovisionnement doit suivre le rythme de celui qui consomme le son.

La figure 1 est un schéma conceptuel qui ne montre que la relation entre réapprovisionnement et consommation. Il ne considère pas les multiples tampons du chemin audio réel comme une seule zone physique. Low Latency Audio

Le rôle du tampon est d’absorber les petits décalages dans le temps entre le côté qui prépare le son et celui qui l’utilise, afin d’assurer une lecture continue. Toutefois, la capacité du tampon et la quantité de données non encore lues qu’il contient à un instant donné sont deux choses différentes. « Avoir une capacité de 10 millisecondes » ne signifie pas qu’il reste toujours 10 millisecondes de son. Rendering a Stream

Nous appelons ici échéance de réapprovisionnement la contrainte temporelle qui impose de fournir les données suivantes nécessaires avant que celles en cours de lecture ne soient épuisées. Le traitement audio exige que les données soient « prêtes avant l’instant où elles doivent sonner ». Il ne suffit pas qu’elles aient « fini par être calculées ». L’état où l’alimentation n’arrive pas à temps et où les données à lire sont épuisées est une sous-alimentation (underrun), qui se traduit par des coupures et des clics. Même si les données arrivent ensuite, la coupure déjà entendue ne peut pas être comblée après coup. Exclusive-Mode Streams

Chemin des données audio

En mode partagé ordinaire, le moteur audio de Windows reçoit les données préparées par l’application de lecture, mélange plusieurs sons et applique des effets, puis transmet le résultat au pilote et au périphérique de sortie. L’application de lecture intervient à la fois dans la lecture de la source audio et dans l’alimentation de la destination de sortie ; le pilote et le périphérique de sortie acheminent les données côté périphérique et les lisent. Low Latency Audio

flowchart TB
    accTitle: Chemin des données audio en mode partagé
    accDescr: Le moteur audio mélange les données préparées par l'application de lecture et leur applique des effets, puis les transmet au pilote, et le périphérique de sortie les lit.
    A["Application : prépare les données"] --> E["Moteur audio : mixage, effets"]
    E --> D["Pilote : achemine au périphérique"]
    D --> O["Périphérique de sortie : lecture"]

Figure 2 : Exemple en mode partagé. Les traitements et les tampons intermédiaires varient selon l’API et le périphérique.

Le périphérique lui-même peut comporter des traitements ou des tampons : le tampon côté application ne détermine donc pas à lui seul la latence globale. Cette explication suppose le chemin du mode partagé et ne signifie pas que toutes les API passent par les mêmes traitements. Low Latency Audio

Réapprovisionner avec 10 millisecondes restantes

Supposons qu’il reste à cet instant 10 millisecondes de données non lues dans le tampon. Si le réapprovisionnement suivant arrive au bout de 8 millisecondes, la lecture s’enchaîne tant qu’il reste des données ; mais s’il est impossible de réapprovisionner avant 12 millisecondes, dans cet exemple simplifié les données sont épuisées à la 10e milliseconde.

flowchart TB
    accTitle: Avec les mêmes 10 millisecondes restantes, le résultat dépend de l'instant du réapprovisionnement
    accDescr: Avec, comme hypothèse d'explication, 10 millisecondes de données à lire, un réapprovisionnement au bout de 8 millisecondes arrive à temps, alors qu'au bout de 12 millisecondes il arrive après l'épuisement.
    A["Reste : 10 ms de son"] --> B{"Réapprovisionnement suivant"}
    B -->|"au bout de 8 ms"| C["La lecture s'enchaîne"]
    B -->|"au bout de 12 ms"| D["Épuisé à 10 ms"]

Figure 3 : Exemple au temps simplifié. Ce qui compte, ce n’est pas seulement d’avoir réapprovisionné, mais le moment où on l’a fait.

Utilisation du processeur et retards de réapprovisionnement

L’utilisation du processeur indique son degré d’occupation sur une période donnée. Elle ne mesure pas la même chose que la possibilité, pour le traitement audio, de s’exécuter à l’instant où il en avait besoin. Même si le processeur a de la marge pendant la majeure partie d’une seconde, un seul intervalle de 12 millisecondes sans réapprovisionnement peut suffire à couper le son. La capacité de traitement restée disponible ensuite ne permet pas de rattraper un instant de lecture déjà passé. CPU Analysis

flowchart TB
    accTitle: Marge moyenne et retard unique de réapprovisionnement
    accDescr: Même si le processeur a de la marge pendant la majeure partie d'une seconde, un seul intervalle de 12 millisecondes sans réapprovisionnement peut suffire à couper le son.
    A["Processeur disponible presque toute la seconde"] --> B["Une fois, 12 ms sans réapprovisionner"]
    B --> C["Ce seul retard coupe le son"]

Figure 4 : Même avec de la marge en moyenne, un instant de lecture passé ne se rattrape pas.

Ce qui consomme le temps disponible avant l’échéance n’est pas seulement le calcul. L’attente avant que le traitement ne démarre et l’attente avant que les données nécessaires n’arrivent en font aussi partie. C’est pourquoi la question de l’investigation ne doit plus être seulement « Quel pourcentage du processeur était utilisé ? », mais « À l’instant où le son s’est coupé, qu’attendait le son suivant ? ».

Attentes sur les données et les verrous

Supposons que le traitement qui prépare les données audio attende la fin de la lecture d’un fichier. Il en va de même s’il attend un verrou détenu par un autre traitement de l’application. Le traitement en attente utilise lui-même peu le processeur, mais côté périphérique la lecture continue et le son restant diminue. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: La lecture avance même pendant une attente qui n'utilise pas le processeur
    accDescr: Pendant que le traitement audio attend des données ou un verrou, ce traitement n'utilise pas le processeur, mais la lecture avance et le son restant diminue ; si le réapprovisionnement prend du retard, le tampon peut s'épuiser.
    A["Le traitement audio attend des données"] --> B["Ce traitement n'utilise pas le processeur"]
    B --> C["Pendant ce temps, la lecture avance"]
    C --> D["Réapprovisionnement en retard : épuisement"]

Figure 5 : Ne pas utiliser le processeur et avoir terminé le travail nécessaire sont deux choses différentes.

DPC, ISR et thread audio

Une ISR est le traitement qui répond à une interruption provenant d’un périphérique. Un DPC est le mécanisme qui reporte le travail restant afin d’écourter le traitement de l’interruption. Les DPC ordinaires s’exécutent avant les threads ordinaires du même processeur logique, et pendant qu’un DPC ou une ISR ordinaire s’exécute, ce processeur logique ne peut pas exécuter de threads ordinaires. Introduction to DPCs, CPU Analysis

Même si le processeur a de la marge dans son ensemble, l’alimentation peut prendre du retard si ces traitements se prolongent ou se répètent souvent sur le processeur dont le traitement audio a besoin. Les documents d’analyse des performances audio et vidéo de Microsoft citent aussi les DPC/ISR longs des pilotes réseau, de stockage, graphiques et autres parmi les causes possibles des coupures. Il ne suffit pas forcément d’examiner le seul périphérique qui produit le son. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Quand la réponse à un périphérique retarde l'exécution audio
    accDescr: Si un DPC ou une ISR ordinaire se prolonge sur le processeur dont le traitement audio a besoin, l'exécution du thread prend du retard, ce qui peut affecter l'échéance de réapprovisionnement.
    A["DPC/ISR sur le même processeur"] -->|"s'ils se prolongent"| B["L'audio doit attendre son tour"]
    B --> C["Le réapprovisionnement prend du retard"]
    C --> D["À épuisement, coupure"]

Figure 6 : Des traitements sans lien avec le périphérique qui produit le son peuvent eux aussi affecter indirectement le réapprovisionnement audio.

On ne peut pas tracer une limite commune du type « si les DPC durent moins de tant de microsecondes, aucun PC n’aura de coupure ». Les valeurs d’avertissement des documents d’évaluation des performances valent pour leurs conditions d’évaluation, et on ne les érige pas en critère de sécurité détaché de l’échéance de réapprovisionnement réelle et de la marge du tampon. Results for the Streaming Media Performance Assessment

Taille du tampon et latence de lecture

Dans les mêmes conditions, accumuler davantage de son à l’avance permet d’absorber plus facilement les retards temporaires de réapprovisionnement, mais le son nouvellement produit doit attendre derrière celui déjà accumulé. Une attente acceptable lorsqu’on se contente d’écouter de la musique devient gênante, sous la forme d’un décalage entre le geste et le son, lorsqu’on joue sur un clavier ou qu’on traite sa voix au microphone pour s’écouter soi-même. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Marge du tampon et retard de réaction
    accDescr: Accumuler davantage de son à l'avance permet d'absorber plus facilement les retards temporaires de réapprovisionnement, mais augmente aussi l'attente avant que le nouveau son ne soit lu.
    A["Accumuler plus de son à l'avance"] --> B["Retards plus faciles à absorber"]
    B -->|"en contrepartie"| C["Le nouveau son attend derrière"]
    C --> D["Le son suit le geste avec retard"]

Figure 7 : Agrandir le tampon est un réglage qui crée de la marge au prix de la réactivité.

Ce n’est ni « plus c’est petit, plus c’est performant », ni « plus c’est grand, mieux c’est ». On prend une marge suffisante pour éviter les coupures tout en conservant la réactivité nécessaire.

Agrandir le tampon crée une marge face aux retards temporaires d’alimentation. Si l’alimentation moyenne elle-même ne suit pas la consommation, agrandir un tampon de taille finie ne fait que repousser le moment où il s’épuise, et cela ne résout pas non plus les déconnexions du périphérique. Ce n’est pas non plus une recommandation selon laquelle le mode exclusif réglerait tout. Exclusive-Mode Streams

Audio de 480 trames à 48 kHz

Une trame PCM est l’unité qui regroupe les échantillons de tous les canaux lus au même instant. Le fait que le son soit en stéréo ne signifie pas qu’il faille doubler le nombre de trames pour calculer la durée. La durée de son que représente un nombre de trames s’obtient par « nombre de trames ÷ fréquence d’échantillonnage » : à 48 kHz, 480 trames font 480 ÷ 48000 secondes, soit 10 millisecondes. Si l’on augmente le nombre de trames en restant à 48 kHz, la durée de son que l’on peut accumuler s’allonge aussi. Rendering a Stream

Cette durée est distincte de la latence totale entre l’appui sur une touche et le moment où l’on entend le son, car il faut aussi compter le temps de l’application, du pilote, du périphérique, des autres tampons et des autres traitements. Les valeurs de réglage d’une DAW se lisent elles aussi en vérifiant l’unité et le tampon concerné. Low Latency Audio

flowchart TB
    accTitle: Durée calculée à partir du nombre de trames et latence totale
    accDescr: Les 10 millisecondes obtenues en divisant 480 trames par 48000 sont la durée que représente le tampon ; en y ajoutant les traitements de l'application, du pilote, du périphérique et d'autres éléments, on obtient la latence totale entre la touche et le son.
    A["480 ÷ 48000"] --> B["10 ms représentées par le tampon"]
    B -->|"d'autres traitements s'ajoutent"| C["Latence totale de la touche au son"]

Figure 8 : La durée calculée à partir du nombre de trames n’est qu’une partie de la latence totale.

Comparer les conditions où la coupure se reproduit

On commence par cerner la combinaison dans laquelle la coupure se reproduit, et l’on ne passe à un enregistrement détaillé que si nécessaire. Ce qui suit est une procédure pour vérifier la cause, et non une liste de remèdes consistant à appliquer tous les changements de réglage d’un coup.

Enregistrez votre travail, attendez la fin des réunions ou des enregistrements réels, puis faites les essais à un volume qui ne fatigue pas les oreilles. Notez la destination de sortie d’origine, les améliorations audio, les valeurs de tampon et le reste, afin de pouvoir revenir en arrière. Ignorez les éléments dont le réglage n’est pas proposé, et ne modifiez pas le Registre ou d’autres paramètres pour faire apparaître des options de réglage.

1. Choisissez une même source audio courte et une durée d’observation, puis vérifiez que la coupure se reproduit dans les conditions d’origine.

   Notez la version de Windows, le nom et la version de l’application, le périphérique de sortie, le mode de connexion et la version du pilote. Consignez aussi l’heure, l’opération et le nombre de coupures. Si la coupure ne se reproduit pas dans les conditions d’origine, ne concluez pas à une amélioration : revenez à la recherche des conditions qui la reproduisent.

2. Choisissez une comparaison dans le tableau suivant et lancez la lecture en ne changeant que cette condition.

   Condition comparée	Ce que l’on examine
   Source enregistrée sur la machine face à une lecture via le réseau	Si la coupure ne survient qu’en lecture via le réseau. Si, à contenu égal, le format ou le chemin de traitement diffère, le noter aussi.
   Même source lue dans une autre application	Si la coupure se concentre sur une application particulière.
   Sortie Bluetooth ou autre face à une sortie intégrée ou filaire	Si la coupure se concentre sur un chemin de sortie particulier.
   Améliorations audio activées ou désactivées	Si le résultat change en combinaison avec le traitement des effets.
   Tampon actuel de la DAW ou autre face à une valeur d’un cran supérieure	Si le résultat change quand on augmente la marge de son accumulé à l’avance. Si le retard entre le geste et le son reste acceptable.

3. Si vous comparez les améliorations audio, désactivez-les temporairement sur la sortie concernée.

   Dans Windows, ouvrez « Paramètres » → « Système » → « Son », sélectionnez la sortie concernée et, dans les environnements où l’option existe, désactivez « Améliorations audio ». Si l’affichage ou la présence des éléments diffèrent, consultez les instructions correspondant à cette version ou à ce périphérique. Fix distorted or crackling audio in Windows

4. Rétablissez le réglage modifié et refaites l’essai avec la même source audio et la même durée d’observation.

   Mettez côte à côte les résultats de la « condition d’origine », de la « condition avec un seul changement » et de la « condition rétablie ». Remettez dans leur état d’origine les changements sans effet avant de passer à une autre comparaison. Si l’on continue de changer les combinaisons de réglages, on ne sait plus ce qui a eu un effet.

5. Si vous essayez de changer de pilote, vérifiez d’abord la distribution officielle et la méthode de restauration.

   Utilisez Windows Update ou la distribution officielle du fabricant du périphérique, et notez la version et les réglages avant et après le changement. Vérifiez à l’avance que vous pourrez revenir en arrière et, sur un PC géré, concertez-vous avec l’administrateur. Une seule lecture réussie juste après la mise à jour ne suffit pas à conclure que le problème est résolu : vérifiez avec les mêmes conditions de reproduction. Fix distorted or crackling audio in Windows

Le résultat recherché est un relevé qui associe symptôme et conditions, du type « la coupure se reproduit avec cette application lorsqu’on utilise cette sortie ». Même si vous trouvez un réglage qui améliore la situation, cela reste distinct de l’établissement de la cause.

flowchart TB
    accTitle: Comparaison qui change une condition puis la rétablit
    accDescr: On vérifie la reproduction avec la même source audio, on change une condition comme l'application ou la sortie, et l'on consigne aussi le résultat après l'avoir rétablie.
    A["Lire avec la combinaison d'origine"] --> B["Changer une condition et lire"]
    B --> C["Rétablir et lire"]
    C --> D["Noter conditions et heure des coupures"]

Figure 9 : Plutôt qu’une amélioration ponctuelle, on vérifie que condition et symptôme se correspondent de façon répétée.

Reproductibilité avant et après un changement

« Le symptôme a pu être atténué », « les conditions ont pu être cernées » et « la cause racine a été identifiée » sont des aboutissements différents. Consignez la conclusion en fonction de ce que vous avez réellement pu observer.

flowchart TB
    accTitle: Trois résultats indiquant un lien avec une condition
    accDescr: Si la coupure se reproduit dans les conditions d'origine, s'améliore quand on change une condition et revient quand on la rétablit, c'est un indice de lien avec cette condition, mais cela reste distinct de l'établissement de la cause.
    A["Reproduite dans la condition d'origine"] --> B["Améliorée en en changeant une"]
    B --> C["Revient après rétablissement"]
    C --> D["Indice de lien avec cette condition"]

Figure 10 : Même si les trois sont réunis, on ne dispose que d’un indice de lien.

Une faible utilisation du processeur ne prouve pas que les échéances audio ont été respectées. De même, le seul fait qu’une coupure se soit produite ne permet pas d’affirmer qu’un retard de réapprovisionnement en était la cause racine. Comparez la source audio, le traitement de l’application, les effets, le chemin de sortie et le reste, et jugez dans les limites de ce que vous avez observé. Fix distorted or crackling audio in Windows

Lorsque vous adoptez un contournement provisoire, consignez le réglage d’origine, le changement effectué, la durée d’observation, la réapparition ou non du problème et la latence acceptable. Si la cause racine n’est pas établie, notez-le également.

Enregistrer la coupure avec WPR

Cette étape s’applique lorsque la comparaison des conditions ne suffit pas à cerner la cause, ou lorsque vous examinez les traitements côté pilote. WPR est l’outil d’enregistrement, et WPA l’outil d’analyse de la chronologie enregistrée. Préparez le Windows Performance Toolkit, les droits nécessaires à l’enregistrement et un emplacement où enregistrer l’ETL. S’il faut installer l’outil et enregistrer sur un PC géré, demandez-le à l’administrateur. Les noms affichés et les profils disponibles se vérifient dans la version installée. Windows Performance Recorder

Un ETL peut contenir des noms de processus, des chemins de fichiers et d’autres informations. Avant d’enregistrer, vérifiez les règles internes et les destinataires du partage, et ne le joignez pas tel quel dans un espace public. Si une autre session d’enregistrement est en cours, ne l’arrêtez pas de votre propre chef : renseignez-vous auprès de la personne responsable. WPR How-to Topics

1. Ouvrez « More Options » dans WPR et choisissez le profil d’enregistrement adapté à l’objectif.

   Les profils intégrés comprennent « Audio glitches » et « CPU usage ». Choisissez une configuration qui permet d’examiner les discontinuités audio et l’activité du processeur. Vérifiez dans la version installée les profils disponibles, leurs noms et ce qu’ils collectent, et ne configurez pas un enregistrement prolongé de tous les types. Built-in Recording Profiles

2. Démarrez l’enregistrement avant de reproduire la coupure.

   Si une confirmation demande d’arrêter un enregistrement existant, ne poursuivez pas : annulez le démarrage et renseignez-vous auprès de la personne responsable. Alignez les conditions sur celles du cas sans enregistrement, et gardez à l’esprit que la charge de l’enregistrement lui-même peut modifier le symptôme. WPR How-to Topics

3. Lancez la lecture dans les conditions trouvées lors de la comparaison, et notez l’heure et l’opération au moment de la coupure.

   Incluez aussi un court intervalle sans problème avant et après le symptôme. Pour un enregistrement où la coupure ne s’est pas reproduite, indiquez-le explicitement, et ne le traitez pas comme un enregistrement ayant capturé la cause.

4. Une fois la coupure reproduite, terminez l’enregistrement avec « Save » et enregistrez le fichier ETL.

   « Cancel » n’enregistre rien. Notez l’emplacement du fichier, les conditions de reproduction, si un enregistrement a été effectué et si un avertissement de perte d’événements est apparu. Dans un enregistrement comportant des pertes, ne considérez pas comme normaux les intervalles invisibles. WPR How-to Topics

Une fois réunis le fichier ETL et les notes indiquant l’heure, l’opération et les conditions de la coupure, tout est prêt pour le recoupement dans WPA. Le seul fait d’avoir enregistré la trace ne garantit pas que les événements nécessaires ont été capturés. Le contenu se vérifie dans la section suivante, « Exécution et attentes autour de la coupure ».

flowchart TB
    accTitle: Prendre un enregistrement court qui inclut la coupure
    accDescr: On démarre l'enregistrement avec WPR, on reproduit le symptôme en notant l'heure, puis on examine dans WPA l'enregistrement arrêté et sauvegardé.
    A["Démarrer l'enregistrement WPR"] --> B["Reproduire la coupure à l'identique"]
    B --> C["Noter heure et opération, sauvegarder"]
    C --> D["Zoomer dans WPA autour de la coupure"]

Figure 11 : L’utilisation du processeur observée une fois le symptôme passé ne suffit pas : il faut un enregistrement de l’intervalle où il s’est produit.

Exécution et attentes autour de la coupure

Préparez l’ETL enregistré et les notes indiquant l’heure de la reproduction. Ce qui suit est un point de départ pour l’investigation dans WPA. Si une analyse détaillée incluant les piles et les symboles devient nécessaire, confiez-la à l’administrateur ou aux développeurs, en faisant attention au traitement de l’enregistrement.

1. Ouvrez l’ETL dans WPA et, en vous appuyant sur les événements audio capturés et sur l’heure de la reproduction, zoomez sur l’intervalle avant et après la coupure.

   Conservez aussi un intervalle sans symptôme pour comparaison. Ne regardez pas seulement le classement des valeurs maximales : comparez en vous alignant sur le même intervalle de temps.

2. Sur ce même intervalle, examinez « DPC/ISR » et « CPU Usage (Precise) ».

   Si les données nécessaires manquent, vérifiez que le profil permet de les obtenir, puis revenez à l’enregistrement WPR. L’absence d’enregistrement et l’absence de problème sont deux choses différentes. CPU Analysis, Built-in Recording Profiles

3. Distinguez si les threads liés à l’audio attendaient leur tour alors qu’ils étaient prêts à s’exécuter, ou s’ils attendaient des données ou autre chose.

   Dans le premier cas, vérifiez si des DPC/ISR ou d’autres traitements se sont exécutés longtemps sur les processeurs logiques concernés. Dans le second, suivez, à l’aide des événements et des piles capturés, ce qui a levé l’attente. Un thread en cours d’exécution pouvant aussi être interrompu, ne vous limitez pas au temps passé à l’état Ready : superposez aussi les intervalles DPC/ISR. CPU Analysis

4. Consignez ensemble la correspondance temporelle avec la coupure, les processeurs concernés et les résultats obtenus en changeant les conditions.

   Ne désignez pas un périphérique ou un pilote particulier comme cause sur la seule base du nom de module d’un DPC/ISR long. Il se peut que vous regardiez une valeur élevée à un autre moment, ou une partie commune traversée par plusieurs périphériques.

flowchart TB
    accTitle: Examiner la nature de l'attente sur l'intervalle de la coupure
    accDescr: On zoome sur l'intervalle avant et après la coupure pour observer l'état du thread audio. S'il attendait son tour en étant prêt, on le recoupe avec les DPC et ISR du même processeur ; s'il attendait des données ou autre chose, on suit le traitement qui a levé l'attente.
    A["Zoomer autour de la coupure"] --> B{"État du thread"}
    B -->|"attend son tour"| C["DPC/ISR"]
    B -->|"attend des données"| D["Ce qui a levé l'attente"]

Figure 12 : Au lieu de relever uniquement les valeurs maximales, on les lit en les superposant à l’intervalle où le traitement audio en avait besoin.

Si la cause ne peut pas être identifiée, l’investigation est transmise comme non conclue. On y joint les versions de l’OS, de l’application, du périphérique et du pilote, la procédure de reproduction, les résultats avant et après les changements, l’heure de survenue, le profil de collecte et la présence ou non d’avertissements de perte. L’ETL n’est partagé, conformément aux règles internes, qu’avec les personnes chargées de l’investigation.

Préchargement dans une application audio

Si vous développez votre propre application audio, concevez-la de sorte que le traitement qui remplit le tampon suivant respecte l’échéance à chaque fois. WASAPI offre un moyen de recevoir par un événement le moment où le tampon peut être traité. Exclusive-Mode Streams

MMCSS est un mécanisme qui attribue des ressources processeur aux threads de traitement multimédia soumis à des contraintes de temps. Il ne dispose d’aucune fonction pour préparer à l’avance les données depuis le disque ni pour supprimer les attentes sur des verrous. Même si vous tirez parti de l’attribution par MMCSS, une conception distincte reste nécessaire pour préparer les données et réduire les attentes. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Ce dont MMCSS se charge
    accDescr: MMCSS attribue des ressources processeur aux threads de traitement soumis à des contraintes de temps, mais la préparation des données et la réduction des attentes sur des verrous relèvent d'une autre conception.
    M["MMCSS : attribue le processeur"] -.->|"nécessaire à part"| D["Préparer les données, réduire les attentes"]

Figure 13 : Attribuer des ressources processeur et concevoir pour que les données arrivent à temps sont deux tâches distinctes.

Le principe de conception consiste à séparer le traitement qui lit depuis des fichiers ou le réseau de celui qui transmet le son. Les préparations dont la durée est difficile à prévoir se font à l’avance, et l’échange passe par un tampon préalloué. Côté audio, on s’organise pour ne pas avoir à attendre une réponse de l’interface utilisateur, un verrou long ou une écriture de journal synchrone.

flowchart TB
    accTitle: Séparer les préparations de durée imprévisible de l'alimentation audio
    accDescr: Conception dans laquelle la lecture et les autres préparations se font dans un traitement anticipé, et les données préparées passent par un tampon vers le traitement audio, afin de réduire les longues attentes juste avant l'échéance.
    A["Préparer les données à l'avance"] --> B["Zone d'échange préallouée"]
    B --> C["L'audio transmet le nécessaire"]
    C --> D["Alimenter la sortie audio"]

Figure 14 : Le travail qui prend du temps est retiré de l’instant qui précède la transmission du son.

Si le côté préparation s’arrête longtemps, le stock s’épuise malgré cette séparation. Outre le temps de traitement moyen, consignez aussi, d’une manière qui ne gêne pas le traitement audio, les occurrences de traitements ou d’attentes longs et le nombre de fois où l’alimentation a échoué. Vérifiez auprès de l’API ou du pilote la taille de tampon et la période réellement retenues, et ne supposez pas que la valeur demandée a été adoptée telle quelle. Rendering a Stream, Low Latency Audio

Les exemples chiffrés comme les exemples de conception sont illustratifs : ce ne sont ni des valeurs de réglage recommandées pour un périphérique particulier, ni une garantie d’absence de coupure dans n’importe quel environnement.

Effet de la priorité temps réel

Il n’est pas recommandé, de manière générale, que l’utilisateur passe tout le lecteur en priorité « Temps réel ». Cela risque de gêner d’autres traitements importants, et élever la priorité d’un thread ordinaire ne fait pas disparaître les attentes dues aux DPC/ISR, aux données ou aux verrous. En développement, on utilise des mécanismes comme MMCSS et une conception qui n’introduit pas de longues attentes dans l’alimentation audio. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Les attentes qui subsistent même en priorité temps réel
    accDescr: Même si le lecteur passe en priorité temps réel, les threads ordinaires ne peuvent pas passer devant les DPC et ISR du même processeur, les attentes sur les données et les verrous subsistent, et il existe en outre un risque de gêner d'autres traitements importants.
    A["Lecteur en priorité temps réel"] --> B["Ne passe pas devant DPC/ISR"]
    B --> C["Les attentes données/verrous restent"]
    C --> D["Risque de gêner d'autres traitements"]

Figure 15 : Même en élevant la priorité, les attentes qui retardent le réapprovisionnement audio subsistent.

Articles connexes

• La « planification du processeur » de Windows et le réglage des services d’arrière-plan
• Diagnostiquer sans risque un disque à 100 % sous Windows
• Pourquoi RDP est-il lent alors que la connexion est rapide ?

Références

• Microsoft Learn, Rendering a Stream. Alimentation du tampon de lecture, quantité restante, taille réelle du tampon et définition de la trame PCM.
• Microsoft Learn, Exclusive-Mode Streams. Instant d’alimentation du tampon et défauts audio, compromis avec la latence et alimentation pilotée par événements. Ce n’est pas une recommandation générale du mode exclusif en tant que tel.
• Microsoft Learn, Low Latency Audio. Chemin audio de Windows ; tampons, périphériques, traitement des effets et latence ; compromis de la faible latence.
• Microsoft Learn, CPU Analysis. Processeurs logiques, états Ready/Waiting des threads, relation entre DPC/ISR et exécution des threads, et analyse du processeur dans WPA.
• Microsoft Learn, Introduction to DPCs. Mécanisme qui écourte le traitement des interruptions et reporte le travail restant à un DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR longs ou fréquents, alimentation insuffisante en données et défauts audio. Les valeurs d’avertissement de l’évaluation ne sont pas généralisées en critère de sécurité pour tous les périphériques.
• Microsoft Support, Fix distorted or crackling audio in Windows. Vérification des améliorations audio, du format, du pilote et d’autres éléments.
• Microsoft Learn, Windows Performance Recorder. Enregistrement ETW, analyse avec WPA et utilisation du Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options de WPR et profils intégrés tels que Audio glitches et CPU usage.
• Microsoft Learn, WPR How-to Topics. Démarrage de l’enregistrement et sauvegarde avec Save, conflits avec des sessions existantes, précautions concernant les informations personnelles et la perte d’événements.
• Microsoft Learn, Multimedia Class Scheduler Service. Attribution de ressources processeur aux traitements multimédias soumis à des contraintes de temps.
• Microsoft Learn, Scheduling Priorities. Priorités des processus et des threads, et précautions concernant la priorité temps réel.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ce sont des pages de sujets proches de ce thème. À partir de l’article, vous pouvez poursuivre vers les services associés et vers d’autres articles.

Services liés à ce sujet

Cet article est directement lié aux services suivants. Commencez par une entrée proche de votre situation.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi le son se coupe-t-il alors que l'utilisation du processeur n'est que d'environ 10 % ?

Le son est soumis à une échéance : les données suivantes doivent être réapprovisionnées avant que celles en cours de lecture ne soient épuisées. Même si l'utilisation globale du processeur est faible, le réapprovisionnement peut ne pas arriver à temps si, à cet instant, le traitement audio n'a pas pu s'exécuter ou attendait des données nécessaires. Toutes les coupures n'ont pas forcément cette cause : il faut aussi des comparaisons en changeant le périphérique de sortie ou l'application.

Agrandir le tampon audio supprime-t-il les coupures ?

Lorsque le réapprovisionnement prend temporairement du retard, un tampon plus grand peut parfois l'absorber. Mais l'attente avant la lecture du son accumulé augmente elle aussi. Ce n'est pas un réglage qui va jusqu'à résoudre un manque durable de capacité de traitement ou les déconnexions du périphérique. Dans les applications et les pilotes qui permettent de le modifier, notez la valeur d'origine et comparez un cran à la fois.

À 48 kHz, combien de millisecondes de son représentent 480 trames ?

480 ÷ 48000 secondes, soit 10 millisecondes. Une trame PCM est l'unité qui regroupe les échantillons de tous les canaux à un même instant. Cette valeur est la durée de son que représente ce nombre de trames, et non la latence totale incluant le périphérique et l'application.

Un pilote dont les DPC ou les ISR s'exécutent longtemps est-il le coupable des coupures ?

C'est un candidat, mais le classement par temps d'exécution ne suffit pas à l'établir. On recoupe l'intervalle où la coupure s'est produite avec les attentes du thread audio et l'exécution des DPC/ISR sur le même processeur. On ne conclut pas à un défaut d'un périphérique ou d'un pilote particulier sur la seule base du nom de module, et l'on vérifie aussi les résultats obtenus en changeant les conditions de reproduction.

Passer le lecteur en priorité temps réel améliore-t-il la situation ?

Ce n'est pas recommandé de manière générale. Élever la priorité d'un thread ordinaire ne lui permet pas de passer devant les DPC et ISR ordinaires du même processeur, et ne fait pas disparaître les attentes sur les données ou les verrous. Les développeurs utilisent des mécanismes comme MMCSS et une conception qui n'introduit pas d'attentes, et les utilisateurs comparent d'abord les conditions de reproduction et le chemin de sortie.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Axé sur le développement de logiciels Windows, le conseil technique et l’analyse de dysfonctionnements, avec un point fort pour les projets où subsistent des actifs existants et pour les enquêtes sur des pannes dont la cause est difficile à discerner.