Pourquoi le son se coupe-t-il alors que l'utilisation du processeur est faible ? — Raisonner en termes de tampons et d'échéances

Vous écoutez de la musique et, de temps en temps, elle se coupe avec un claquement. Vous ouvrez le Gestionnaire des tâches et l’utilisation du processeur tourne autour de 10 %. La vidéo continue de se lire et la souris se déplace normalement.

On a envie de demander : « avec toute cette marge, lire du son serait-il vraiment trop demander ? »

Mais ce dont l’audio a besoin, ce n’est pas seulement la capacité d’abattre beaucoup de travail rapidement. Il lui faut aussi que le prochain fragment de son soit prêt avant que celui en cours ne s’épuise. Cet article suit ce réapprovisionnement tardif, le mécanisme qui se cache derrière une coupure typique.¹

Nous partons de la lecture de musique sur un PC. Les sections 1 à 4 achèvent l’exposé du mécanisme, et la section 5 et les suivantes rassemblent les méthodes d’investigation. On suppose tout du long une sortie audio sous Windows 11, et les chiffres sont des hypothèses servant à l’explication.

1. L’audio se lit pendant qu’un peu de la suite est tenu en réserve

Un fichier musical stocké sur le PC ne fait pas sonner les haut-parleurs par sa seule présence. L’application de lecture prépare les données audio et les achemine, via Windows et le pilote, jusqu’au périphérique qui produit le son. Dans le mode partagé habituel, le moteur audio de Windows mélange plusieurs flux et applique des effets en chemin.²

Si l’audio était remis morceau par morceau exactement au moment où il est nécessaire, le moindre retard de traitement se répercuterait directement sur la lecture. C’est pourquoi un peu de ce qui sera lu ensuite est tenu en réserve à l’avance. Ce lieu de rétention temporaire est le tampon. Pendant que la lecture progresse du côté du périphérique, l’application et le traitement audio le réapprovisionnent avec les données suivantes.³

flowchart TB
    accTitle: Mettre un peu de son en tampon, puis le lire
    accDescr: Le flux consistant à réapprovisionner le tampon avec des données audio préparées et à préparer les données suivantes pendant que la lecture progresse du côté du périphérique.
    A["Préparer les données audio suivantes"] --> B["Réapprovisionner le tampon"]
    B --> C["Lire l'audio mis en tampon"]
    C -.->|"Avant que le reste ne s'épuise"| A

Figure 1 : Pour que la lecture continue, le réapprovisionnement doit suivre le rythme du côté qui consomme l’audio.

Supposons que le tampon contienne actuellement 10 millisecondes d’audio. Si le prochain réapprovisionnement arrive dans 8 millisecondes, il enchaîne alors qu’il en reste encore. Mais si rien n’arrive avant 12 millisecondes, le stock est épuisé au repère des 10 millisecondes.

flowchart TB
    accTitle: Les mêmes 10 millisecondes restantes, un résultat différent selon le moment du réapprovisionnement
    accDescr: En hypothèse servant à l'explication, on montre que pour 10 millisecondes de données de lecture restantes un réapprovisionnement 8 millisecondes plus tard arrive à temps, tandis qu'un réapprovisionnement 12 millisecondes plus tard arrive après l'épuisement.
    A["Il reste 10 millisecondes à l'instant"] --> B["Réapprovisionnement 8 ms plus tard"]
    B --> C["Enchaîne alors qu'il en reste"]
    A --> D["Réapprovisionnement 12 ms plus tard"]
    D --> E["Stock épuisé à 10 ms"]

Figure 2 : Un exemple simplifié en termes de temps. Ce qui compte n’est pas seulement que le réapprovisionnement ait eu lieu, mais quand.

Être à court parce que la fourniture des données audio nécessaires n’arrive pas à temps est un sous-alimentation de tampon. Elle entraîne coupures, clics et artefacts semblables. Même si les données arrivent en retard, un blanc déjà entendu ne peut pas être comblé après coup.¹

La lecture audio est un travail pour lequel « ça a fini par être calculé » ne suffit pas ; ce qu’il faut, c’est « c’était prêt au moment où il fallait le jouer ».

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

2. Pourquoi le réapprovisionnement est en retard alors que le processeur est inoccupé

En entendant cela, la réaction naturelle est : « alors si le processeur est inoccupé, pourquoi ne pas réapprovisionner plus tôt ? »

Mais le chiffre d’utilisation du processeur n’est pas un décompte des échéances audio respectées. À quel point l’ensemble du processeur a été occupé sur un intervalle et si le court travail qui réapprovisionne l’audio a pu s’exécuter au moment voulu sont deux choses distinctes. Une charge globale faible ne garantit pas que le travail audio obtienne son tour immédiatement à chaque fois.⁴

Dans les termes de l’exemple précédent, même s’il y a de la marge pendant l’essentiel d’une seconde, un seul intervalle où le réapprovisionnement ne peut pas avoir lieu pendant 12 millisecondes épuise les 10 millisecondes d’audio restantes. La marge présente plus tard dans la seconde ne rattrape pas cette unique arrivée tardive.

Pas un calcul lent, mais l’attente d’une occasion de s’exécuter

Supposons que le code qui prépare les données audio attende la fin d’une lecture de fichier. Ou qu’il attende un verrou détenu par un autre travail au sein de l’application. Pendant qu’il attend, ce code lui-même consomme peu de processeur. L’audio déjà en cours de lecture continue de s’écouler malgré tout. Une fourniture de données tardive et un thread en attente se produisent indépendamment de l’épuisement du processeur.⁵⁴

flowchart TB
    accTitle: La lecture progresse même pendant un temps d'attente qui ne consomme pas de processeur
    accDescr: La lecture progresse pendant que le traitement audio attend des données ou un verrou, si bien que le tampon peut se vider avec une utilisation du processeur toujours faible.
    A["Le traitement audio attend des données"] --> B["Ce travail ne consomme pas de processeur"]
    A --> C["La lecture continue et le reste diminue"]
    C --> D["Un réapprovisionnement tardif signifie être à court"]

Figure 3 : « Ne pas utiliser le processeur » n’est pas la même chose que « le travail nécessaire est fait ».

Des périphériques apparemment étrangers à l’audio peuvent aussi le retarder

Il y a un second cas, où le tour ne revient pas du côté de Windows.

Lorsqu’une notification arrive d’un périphérique réseau ou assimilé, Windows exécute du code qui traite l’interruption. La courte première portion de ce travail est l’ISR, et le mécanisme qui diffère le reste du travail est le DPC. Pendant qu’un DPC ou une ISR ordinaire s’exécute, ce processeur logique ne peut pas exécuter de threads ordinaires. Le traitement audio y est soumis lui aussi.⁶⁴

Lorsqu’un tel travail s’exécute longtemps ou souvent sur le processeur où l’audio doit s’exécuter, l’occasion de réapprovisionner l’audio est repoussée. La documentation d’analyse de performances de Microsoft pour l’audio et la vidéo explique elle aussi que des DPC et ISR longs provenant de pilotes réseau, de stockage, graphiques et autres peuvent provoquer des artefacts audio.⁵

flowchart TB
    accTitle: Quand répondre à un périphérique retarde l'exécution de l'audio
    accDescr: Lorsqu'un DPC ou une ISR ordinaire s'exécute longtemps sur le processeur dont le traitement audio a besoin, l'exécution du thread est retardée et l'échéance de réapprovisionnement peut en être affectée.
    A["DPC ou ISR sur le même processeur"] -->|"Quand il s'exécute longtemps"| B["L'exécution de l'audio est retardée"]
    B --> C["Le réapprovisionnement suivant est en retard"]
    C --> D["Une coupure une fois le reste épuisé"]

Figure 4 : Pas seulement le périphérique qui produit le son ; le travail destiné à d’autres périphériques peut avoir un effet indirect.

Autrement dit, une coupure n’est pas seulement « le processeur est trop lent pour terminer le calcul ». Le calcul ne peut pas démarrer, ou les données dont il a besoin n’arrivent pas. Cette attente-là aussi est du temps pris sur l’échéance de l’audio.

3. Alors pourquoi ne pas simplement tenir beaucoup d’audio en réserve ?

Si le réapprovisionnement est un peu en retard, il paraît sensé de garder assez de stock pour absorber ce retard. C’est exactement le raisonnement qui conduit à agrandir le tampon audio.

À conditions égales, tenir davantage d’audio à l’avance rend les courts retards de réapprovisionnement plus faciles à encaisser. Mais désormais l’audio nouvellement produit attend derrière l’audio déjà tenu en réserve.¹²

Si vous ne faites qu’écouter de la musique, attendre un instant après avoir appuyé sur Lecture ne vous gênera peut-être pas. Quand vous jouez d’un clavier relié au PC, ou que vous traitez votre propre voix depuis un micro pour vous écouter, cette attente devient un écart entre le geste et le son.

flowchart TB
    accTitle: Marge du tampon et réponse plus lente
    accDescr: Tenir davantage d'audio à l'avance rend les retards temporaires de réapprovisionnement plus faciles à absorber, tandis que l'attente avant que le nouvel audio ne soit lu augmente elle aussi.
    A["Tenir davantage d'audio à l'avance"] --> B["Les retards de réapprovisionnement s'absorbent mieux"]
    A --> C["Le nouvel audio attend derrière"]
    C --> D["Plus de délai entre le geste et le son"]

Figure 5 : Augmenter le tampon est un ajustement qui achète de la marge au prix de la réactivité.

Les réglages de tampon 128, 256 et 512 que l’on trouve dans les logiciels de production musicale se rapportent eux aussi à ce temps. En PCM, l’unité qui regroupe les échantillons de tous les canaux au même instant s’appelle une trame. À 48 kHz, 480 trames font 480 divisé par 48000 secondes, soit 10 millisecondes d’audio. À fréquence d’échantillonnage égale, plus il y a de trames, plus le fragment d’audio qu’elles contiennent est long.³

Ce qui a été compté ici est la durée d’audio que ce tampon représente. En pratique, il y a aussi du traitement dans l’application, le pilote et le périphérique : gardez donc cela distinct de la latence totale entre l’appui sur une touche et l’audition de la note. Toutes les applications sous Windows ne partagent pas non plus un réglage de tampon commun ; les tailles disponibles varient également selon le périphérique et le pilote.²

Plus petit n’est donc pas plus performant, et plus grand n’est pas non plus la bonne réponse. L’ajustement consiste à conserver la réactivité dont vous avez besoin tout en prenant assez de marge pour éviter les coupures.

4. Ce dont l’audio a besoin, c’est de respecter des échéances, pas d’une vitesse moyenne

Revenons à la question initiale.

Le son se coupe à faible utilisation du processeur parce qu’avoir de la marge en capacité globale de traitement et livrer à temps le prochain fragment de son sont deux choses distinctes.

L’audio se lit à partir d’une petite quantité tenue en réserve. Ce stock est réapprovisionné avant d’être épuisé. Un seul réapprovisionnement tardif peut suffire à provoquer un blanc, et augmenter le stock apporte de la marge mais allonge aussi le délai avant que le nouvel audio ne soit entendu.

Voilà le cœur du mécanisme. La question que l’on se pose en investiguant change elle aussi, de « à quel pourcentage était le processeur » à « à l’instant où le son s’est coupé, qu’attendait le prochain fragment de son ». À partir d’ici vient la partie investigation, pour circonscrire un symptôme réel.

5. Investigation : trouvez d’abord quelle combinaison se coupe

Un claquement que vous avez entendu n’établit pas à lui seul la sous-alimentation décrite jusqu’ici. Le matériau source lui-même, le traitement de l’application, les effets audio, le périphérique de sortie et d’autres problèmes produisent des symptômes semblables. La documentation de dépannage de Microsoft cite elle aussi les améliorations audio, le format et les pilotes parmi les points à vérifier.⁷

Ne modifiez pas les réglages en bloc au départ. Lisez la même source courte pendant à peu près la même durée et comparez les différences une à une. Faites-le en dehors d’une réunion ou d’un enregistrement en cours, après avoir sauvegardé votre travail, et à un volume ménageant vos oreilles.

Dans cet ordre, la plainte en une ligne « le son se coupe » peut devenir assez concrète pour dire « il se coupe uniquement dans cette application, quand cette sortie est utilisée ». Revenir sur chaque changement et réessayer permet aussi de mieux distinguer si le symptôme ne s’est simplement pas manifesté par hasard.

flowchart TB
    accTitle: Comparaison qui change une condition puis revient en arrière
    accDescr: Confirmer la reproduction avec la même source, changer une condition comme l'application ou la sortie, et consigner aussi le résultat après être revenu en arrière.
    A["Lire avec la combinaison d'origine"] --> B["Changer une condition et lire"]
    B --> C["Revenir en arrière et lire"]
    C --> D["Consigner les conditions et les heures des coupures"]

Figure 6 : Plutôt qu’une amélioration ponctuelle, confirmez que la condition et le symptôme concordent de façon répétée.

Notez que changer la sortie change aussi le pilote, les tampons, et davantage. « Ça ne coupe pas en filaire » est un indice pour investiguer le chemin de sortie, mais cela n’établit pas à soi seul la liaison sans fil comme cause. De même, une amélioration obtenue avec un tampon plus grand est un indice que davantage de marge temporelle a aidé ; cela ne prouve pas un défaut d’un pilote particulier.

Pour comparer les améliorations audio, sélectionnez la sortie concernée dans Paramètres > Système > Son sous Windows et, là où c’est disponible, désactivez les améliorations audio puis réessayez. Notez le réglage d’origine et rétablissez-le s’il ne change rien. Obtenez les pilotes via Windows Update ou la distribution officielle du fabricant du périphérique, et consignez les versions avant et après le changement.⁷

6. Investigation : enregistrez l’instant de la coupure et zoomez dessus

Lorsque la comparaison des conditions ne circonscrit rien, ou que vous soupçonnez un traitement du côté du pilote, enregistrez ce qui se passe sur un court intervalle. Windows Performance Recorder (WPR) réalise l’enregistrement, et Windows Performance Analyzer (WPA) est l’outil pour examiner en détail la chronologie enregistrée.⁸

Démarrez l’enregistrement avant de reproduire le problème

Sur une machine où le Windows Performance Toolkit est installé, ouvrez More Options dans la fenêtre de WPR. Les profils intégrés comprennent Audio glitches et CPU usage. En partant du premier, choisissez un enregistrement permettant d’examiner les discontinuités audio en même temps que l’activité du processeur. Vérifiez les profils disponibles et leurs noms d’affichage dans la version que vous avez installée.⁹

Démarrez l’enregistrement, puis lisez de l’audio dans les conditions repérées plus tôt. Notez les heures des coupures et ce que vous faisiez et, après avoir reproduit le symptôme, terminez l’enregistrement avec Save pour écrire le fichier ETL. Cancel ne l’enregistre pas. Inclure un peu d’un intervalle sain vous donne un point de comparaison. Si l’on vous invite à arrêter un enregistrement existant, annulez le démarrage et voyez avec la personne responsable, afin de ne pas interrompre une autre investigation.¹⁰

flowchart TB
    accTitle: Prendre un court enregistrement incluant la coupure
    accDescr: Démarrer un enregistrement dans WPR, reproduire le symptôme et noter l'heure, puis arrêter et enregistrer la capture et l'examiner dans WPA.
    A["Démarrer l'enregistrement dans WPR"] --> B["Reproduire la coupure dans les mêmes conditions"]
    B --> C["Noter l'heure et les actions, puis enregistrer"]
    C --> D["Zoomer sur l'intervalle environnant dans WPA"]

Figure 7 : Conservez l’intervalle où le symptôme s’est produit, pas l’utilisation du processeur après coup.

Un fichier ETL peut contenir des noms de processus, des chemins de fichiers et autres : suivez donc les règles de votre organisation et ne le partagez qu’avec les personnes qui en ont besoin. L’enregistrement peut exiger des privilèges ou des outils supplémentaires ; sur un PC d’entreprise, adressez-vous à un administrateur. Comme la charge de l’enregistrement lui-même peut modifier le symptôme, notez si un enregistrement était en cours. Préférez un court enregistrement adapté à votre objectif à un long avec tous les fournisseurs activés. Dans un enregistrement signalant des événements perdus, ne jugez pas sains les intervalles que vous ne voyez pas.¹⁰

Ce qui s’est passé au même moment, plutôt qu’un classement des grands nombres

Dans WPA, zoomez autour de la coupure à l’aide des événements audio capturés et des heures notées. Sur ce même intervalle de temps, examinez DPC/ISR ainsi que CPU Usage (Precise), qui montre l’exécution et les attentes des threads. Si ces données manquent, vérifiez si le profil capture les événements nécessaires et enregistrez de nouveau. Une absence d’enregistrements n’équivaut pas à une absence de problème.⁴⁹

Le point de départ est de voir si le thread lié à l’audio était prêt à s’exécuter mais attendait son tour, ou ne pouvait pas s’exécuter parce qu’il attendait des données ou quelque chose d’analogue. Dans le premier cas, cherchez des DPC, des ISR et assimilés s’exécutant longtemps sur ce processeur. Dans le second, retracez ce qui a levé l’attente, à l’aide des enregistrements et des piles disponibles. Comme un thread en cours d’exécution peut lui aussi être interrompu, ne vous limitez pas au seul temps Ready ; superposez les intervalles pendant lesquels des DPC et des ISR se sont exécutés.⁴

flowchart TB
    accTitle: Examiner comment l'attente s'est produite pendant l'intervalle de la coupure
    accDescr: Pour le thread audio dans l'intervalle considéré, séparer l'attente à l'état prêt de l'attente sur des données ou assimilé, et recouper les enregistrements correspondants.
    A["Le même intervalle autour de la coupure"] --> B["Prêt à s'exécuter mais attendant son tour"]
    A --> C["Attendant des données ou assimilé"]
    B --> D["Recouper le travail sur le même processeur"]
    C --> E["Retracer ce qui a levé l'attente"]

Figure 8 : Ne relevez pas les seules valeurs maximales ; lisez-les superposées à l’intervalle où le traitement audio était nécessaire.

Même si vous trouvez un DPC ou une ISR long, ne regardez pas le nom du module pour décider aussitôt « c’est ce pilote le coupable ». Vous regardez peut-être une valeur élevée relevée à un autre moment, ou un composant partagé par lequel plusieurs périphériques passent. Combinez la correspondance temporelle avec la coupure, les processeurs concernés et les résultats des changements de conditions, et demandez au fabricant du périphérique d’investiguer si nécessaire.

On ne peut pas non plus tracer une ligne universelle du type « un DPC en dessous de tant de microsecondes ne provoque jamais de coupure sur aucun PC ». Les seuils d’avertissement de la documentation sont conditionnés par cette évaluation. Ne les utilisez pas comme un test de conformité détaché de l’échéance de réapprovisionnement réelle et de la marge du tampon.⁵

7. Pour les développeurs : n’introduisez pas de longues attentes dans le code qui remet l’audio

Quand vous construisez vous-même une application audio, le point de départ est le même. Le code qui remplit le tampon suivant doit respecter chaque échéance.

WASAPI offre un moyen de recevoir, sous forme d’événement, le moment où un tampon peut être traité. MMCSS, de son côté, facilite l’attribution de temps processeur aux threads effectuant un travail multimédia sous contrainte temporelle. Ni l’un ni l’autre n’est toutefois une magie qui supprime les attentes. MMCSS ne préparera pas non plus pour vous les données audio depuis le disque à l’avance.¹¹¹

La conception qui convient consiste à séparer le code qui lit depuis des fichiers ou le réseau du code qui remet l’audio. Effectuez à l’avance le travail dont le comportement temporel est difficile à prévoir, et utilisez un tampon préalloué pour la remise. Du côté audio, faites en sorte qu’il n’y ait pas besoin d’attendre une réponse d’interface, un verrou long, une écriture de journal synchrone ou assimilé. C’est une règle de conception pour découpler les attentes de données de l’échéance.

flowchart TB
    accTitle: Séparer la préparation difficile à prévoir de la fourniture audio
    accDescr: Une conception qui effectue à l'avance les lectures et travaux analogues et transmet les données préparées au traitement audio via un tampon, réduisant les longues attentes juste avant l'échéance.
    A["Préparer les données dans un travail fait à l'avance"] --> B["Zone de remise préallouée"]
    B --> C["Remettre au traitement audio ce dont il a besoin"]
    C --> D["Alimenter la destination de sortie audio"]

Figure 9 : Il ne s’agit pas d’éliminer le travail lent, mais de le sortir de l’instant qui précède la remise de l’audio.

Même avec cette séparation, le stock s’épuise si le côté préparation se bloque longtemps. Au-delà du temps de traitement moyen, consignez les occasions où un traitement ou une attente a duré longtemps et le nombre d’échecs de fourniture, d’une manière qui ne perturbe pas le traitement audio. Vérifiez la taille de tampon et la période réellement retenues via l’API ou le pilote, et ne supposez pas que « la valeur que j’ai indiquée a été adoptée telle quelle ».³²

Évitez de recommander aux utilisateurs de régler tout le lecteur sur la priorité temps réel. Cela risque d’entraver d’autres travaux importants, et élever la priorité d’un thread ordinaire ne résout ni les DPC, ni les ISR, ni les attentes de données.¹²⁴

8. Résumé : une faible utilisation du processeur n’est pas la preuve que l’échéance audio a été respectée

Il y a trois axes pour penser les coupures : tenir de l’audio en réserve, le réapprovisionner avant qu’il ne soit épuisé, et un réapprovisionnement tardif signifie un blanc. Même à faible utilisation du processeur, une attente au moment critique peut mettre le réapprovisionnement en retard.

Commencez par comparer applications et sorties avec la même source, et si cela n’explique toujours rien, enregistrez l’intervalle de la coupure. Passer de « pourquoi, alors que le processeur a de la marge » à « qu’attendait-il à cet instant » fait apparaître la prochaine chose à examiner.

Articles liés

• Réglages de planification du processeur sous Windows et services d’arrière-plan
• Circonscrire sans risque un disque Windows à 100 %
• Pourquoi RDP est-il lent sur une connexion rapide ?

Liens de référence

Articles associés

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

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

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 % ?

L'audio a 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 lorsque l'utilisation globale du processeur est faible, le réapprovisionnement peut manquer cette échéance si le traitement audio n'a pas pu s'exécuter à cet instant ou attendait les données nécessaires. Toutes les coupures n'ont pas cette cause : il faut aussi des comparaisons changeant le périphérique de sortie et l'application.

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

Lorsque le réapprovisionnement est temporairement en retard, un tampon plus grand peut l'absorber. Mais l'attente avant que l'audio stocké ne soit lu augmente elle aussi. Ce n'est pas un réglage qui résout un déficit durable de capacité de traitement ou un périphérique qui se déconnecte. Dans les applications et pilotes où cela se modifie, notez la valeur d'origine et comparez une étape à la fois.

À 48 kHz, combien de millisecondes d'audio représentent 480 trames ?

C'est 480 divisé par 48000 secondes, soit 10 millisecondes. Une trame PCM est l'unité qui regroupe les échantillons de tous les canaux au même instant. Cette valeur est la durée d'audio que ce nombre de trames représente, pas 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 d'une coupure ?

C'est un candidat, mais un classement fondé sur le seul temps d'exécution ne tranche pas. Recoupez l'intervalle où la coupure s'est produite avec les attentes du thread audio et avec l'exécution des DPC/ISR sur le même processeur. Ne concluez pas d'un simple nom de module qu'un périphérique ou un pilote est défectueux, et vérifiez aussi les résultats obtenus en changeant les conditions de reproduction.

Régler le lecteur sur la priorité temps réel améliore-t-il les choses ?

Pas en recommandation générale. Élever la priorité d'un thread ordinaire ne permet pas de passer devant les DPC et ISR ordinaires du même processeur, et cela ne supprime pas les attentes sur des données ou des verrous. Les développeurs devraient utiliser des mécanismes comme MMCSS avec une conception qui n'introduit aucune attente dans le chemin audio, tandis que les utilisateurs devraient d'abord comparer les conditions de reproduction et les chemins de sortie.

Profil de l’auteur

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

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.