Profilage des applications audio Web dans Chrome

Découvrez comment profiler les performances des applications Web Audio dans Chrome en utilisant chrome://tracing et le WebAudio onglet dans DevTools.

4 mai 2020

Vous êtes venu à cette documentation probablement parce que vous développez une application qui utilise le API Web Audio
et rencontré des problèmes inattendus, tels que des bruits sur la sortie. Vous êtes peut-être déjà impliqué dans un crbug.com
discussion et un ingénieur Chrome vous a demandé d'importer des "données de trace". Ce guide explique comment obtenir les données afin que vous puissiez aider les ingénieurs à classer et éventuellement à résoudre le problème.

Il existe deux outils pour vous aider à créer des profils audio Web,
chrome://tracing et le WebAudio onglet dans Chrome DevTools.

Lorsque vous utilisez chrome://tracing?

Lorsque de mystérieux «échecs» se produisent. Le profilage de l'application avec les outils de suivi vous donne des informations sur:

• Morceaux de temps passé sur des appels de fonction spécifiques dans différents fils
• Temps de rappel audio dans la vue chronologique

Il affiche généralement des délais manqués ou des arrêts de nettoyage de la mémoire importants qui peuvent provoquer des problèmes audio inattendus. Ces informations sont utiles pour détecter une erreur. Les ingénieurs de Chromium demanderont des données de trace si la reproduction locale du problème n'est pas possible. Regarder L'outil de profilage des événements de suivi pour obtenir des instructions générales sur la façon de suivre.

Quand utilisez-vous le WebAudio langue?

Lorsque vous souhaitez avoir une idée des performances de votre application dans le monde réel. DevTools vous montre une estimation en cours du débit, indiquant comment le moteur de rendu audio Web gère les tâches de rendu avec un budget de rendu donné (par exemple, environ 2,67 ms à 48 kHz). Si la capacité est proche de 100%, cela signifie que votre application est susceptible de se bloquer car le moteur de rendu ne peut pas terminer le travail avec le budget de rendu.

Utiliser chrome://tracing

Comment capturer les données de trace

Les instructions écrites ci-dessous concernent Chrome 80 et versions ultérieures.

Pour de meilleurs résultats, fermez tous les autres onglets et fenêtres et désactivez les extensions. Alternativement, vous pouvez lancer une nouvelle instance de Chrome
ou utilisez d'autres compilations de différents canaux de lancement (par exemple Beta ou Canary). Une fois que vous avez le le navigateur prêt, suivez les étapes ci-dessous :

1. Ouvrez votre application (page Web) dans un onglet.

2. Ouvrez un autre onglet et accédez à chrome://tracing.

3. appuie sur le Graver et sélectionnez Sélectionnez manuellement les paramètres.

4. appuie sur le Rien boutons sur les deux Catégories d'enregistrement y
   Désactivé par les catégories par défaut sections.

5. Dans le Catégories d'enregistrement section, sélectionnez ce qui suit:

   • l'audio
   • blink_gc
   • moitié
   • v8.execute (si vous êtes intéressé AudioWorklet Performance du code JS)
   • webaudio

6. Dans le Désactivé par les catégories par défaut section, sélectionnez ce qui suit:

   • audio-worklet (si vous êtes intéressé par où AudioWorklet le fil commence)
   • webaudio.audionode (si vous avez besoin du suivi détaillé de chaque AudioNode)

7. appuie sur le Graver bouton en bas.

8. Revenez à l'onglet de votre application et suivez les étapes qui ont à nouveau déclenché le problème.

9. Lorsque vous avez suffisamment de données de suivi, revenez à l'onglet de suivi et appuyez sur Arrêter.

10. L'onglet de suivi affichera le résultat.

    

11. presse Sauvegarder pour enregistrer les données de suivi.

Comment analyser les données de trace

Les données de suivi visualisent la manière dont le moteur audio Web de Chrome traite l'audio. Le moteur de rendu a deux modes de rendu différents: Mode natif y
Mode Worklet. Chaque mode utilise un modèle de thread différent, de sorte que les résultats du suivi diffèrent également.

Mode natif

En mode natif, le AudioOutputDevice thread exécute tout le code audio Web. Les AudioOutputDevice est un fil de discussion prioritaire en temps réel qui provient du service audio du navigateur et est piloté par l'horloge du navigateur. Matériel audio. Si vous remarquez une irrégularité dans les données de suivi dans cette voie, cela signifie que le temps de rappel de l'appareil peut être instable. La combinaison de Linux et Pulse Audio est connue pour avoir ce problème. Consultez les problèmes Chromium suivants pour plus de détails : # 825823,
# 864463.

Mode Worklet

En mode Worklet, qui se caractérise par un saut de thread depuis
AudioOutputDevice au AudioWorklet filVous devriez voir des traits bien alignés sur deux lignes de fil, comme indiqué ci-dessous. Lorsque le worklet est activé, toutes les opérations audio Web sont traitées par le
AudioWorklet fil. Ce thread n'est actuellement pas une priorité en temps réel. L'irrégularité commune ici est un gros crash causé par le ramasse-miettes ou le non-respect des délais de traitement. Les deux cas provoquent des échecs dans la transmission audio.

Dans les deux cas, les données de suivi idéales sont caractérisées par des appels de rappel de périphérique audio bien alignés et des tâches de rendu qui sont effectuées dans le budget de rendu donné. Les deux captures d'écran ci-dessus sont d'excellents exemples de données de trace idéales.

Apprenez à partir d'exemples du monde réel

Exemple 1: tâches de rendu qui vont au-delà du budget de rendu

La capture d'écran ci-dessous (Problème de chrome # 796330) est un exemple typique de quand le code dans AudioWorkletProcessor cela prend trop de temps et dépasse un budget de rendu donné. Le temps de rappel se comporte bien, mais l'appel à la fonction de traitement audio API Web Audio n'a pas pu terminer la tâche avant le prochain rappel du périphérique.

Vos options:

• Réduisez la charge de travail des graphiques audio en utilisant moins AudioNode instances.
• Réduisez la charge de travail de votre code sur AudioWorkletProcessor.
• Augmentez la latence de base de AudioContext.

Exemple 2: garbage collection important sur le thread du worklet

Contrairement au thread de rendu audio natif, le garbage collection est géré dans le thread du worklet. Cela signifie que si votre code alloue / désalloue de la mémoire (par exemple, de nouveaux tableaux), il déclenche finalement un garbage collection qui verrouille de manière synchrone le thread. Si la charge de travail pour les opérations audio Web et le garbage collection est supérieure à un budget de rendu donné, la diffusion audio échoue. La capture d'écran suivante est un exemple extrême de ce cas.

Vos options:

• Allouez de la mémoire à l’avance et réutilisez-la à tout moment être possible.
• Utilisez différents modèles de conception basés sur SharedArrayBuffer. Bien que ce ne soit pas une solution parfaite, plusieurs applications audio Web utilisent un modèle similaire avec
  SharedArrayBuffer pour exécuter le code audio intensif. Exemples:

Exemple 3: rappel de périphérique audio nerveux depuis AudioOutputDevice

La synchronisation précise du rappel audio est la chose la plus importante pour l'audio Web. Cela devrait être l'horloge la plus précise de votre système. Si le système d'exploitation ou son sous-système audio ne peut pas garantir un temps de rappel robuste, toutes les opérations ultérieures seront affectées. L'image ci-dessous est un exemple de rappel audio audacieux. Par rapport aux deux images précédentes, l'intervalle entre chaque rappel varie considérablement.

Il s'agit d'un problème connu sous Linux, qui utilise Pulse Audio comme backend audio. Ceci est toujours sous enquête (Problème de chrome non. 825823).

Vous pouvez également utiliser l'onglet DevTools spécialement conçu pour l'audio Web. Ceci est moins complet que l'outil de suivi, mais il est utile si vous souhaitez mesurer les performances d'exécution de votre application.

Accédez au panneau en ouvrant le Menu principal à partir de DevTools, puis accédez à Plus d'outils > WebAudio.

Cet onglet affiche des informations sur l'exécution des instances de BaseAudioContext. Utilisez-le pour voir les performances du moteur de rendu audio Web sur la page.

Puisqu'une page peut avoir plusieurs BaseAudioContext instances, le Sélecteur de contexte
(qui est la liste déroulante qui dit temps réel (4e1073) dans la dernière capture d'écran), vous permet de choisir ce que vous souhaitez inspecter. La vue de l'inspecteur affiche les propriétés (par exemple, la fréquence d'échantillonnage, la taille de la mémoire tampon, le nombre de canaux et l'état du contexte) d'un BaseAudioContext l'instance que vous sélectionnez, et elle change de manière dynamique lorsque les propriétés changent.

La chose la plus utile dans cette vue est la barre d'état en bas. Il n'est actif que lorsque le BaseAudioContext c'est un AudioContext, qui s'exécute en temps réel. Cette barre montre la qualité de la transmission audio instantanée d'un AudioContext et se met à jour toutes les secondes. fournissez les informations suivantes:

• Intervalle de rappel (ms) - Affiche la moyenne / variance pondérée de l'intervalle de rappel. Idéalement, la moyenne devrait être stable et la variance devrait être proche de zéro. Sinon, l'infrastructure audio du système d'exploitation pourrait avoir des problèmes dans des couches plus profondes.
• Capacité de rendu (pourcentage): suivez cette formule: (temps passé sur le rendu réel / intervalle de rappel instantané) × 100. Lorsque la capacité approche 100%, cela signifie que le moteur de rendu en fait trop pour un budget de rendu donné, vous devriez donc envisager d'en faire moins dans votre code audio Web.

Vous pouvez manuellement et activer un ramasse-miettes en cliquant sur l'icône de la poubelle.

conclusion

Le débogage audio est difficile. Le débogage audio dans le navigateur est encore plus difficile. Cependant, ces outils peuvent soulager la douleur en vous fournissant des informations utiles sur le fonctionnement du code audio Web. Dans certains cas, l'audio Web peut ne pas se comporter comme il se doit; alors n'ayez pas peur de
signaler un bogue dans Chromium Bug Tracker. Tout en remplissant les informations, vous pouvez suivre le guide ci-dessus et soumettre les données de trace que vous avez capturées avec un scénario de test reproductible. Avec ces données, les ingénieurs Chrome pourront corriger votre erreur beaucoup plus rapidement.

Photo de Jonathan Velasquez dans Unsplash