Profilerstellung für Web-Audio-Apps in Chrome

Hier erfahren Sie, wie Sie die Leistung von Web Audio-Apps in Chrome mit about://tracing und Audion (einer WebAudio -Erweiterung in den Chrome-Entwicklertools) analysieren.

Sie sind wahrscheinlich auf diesen Artikel gestoßen, weil Sie eine App entwickeln, die die Web Audio API verwendet, und unerwartete Fehler aufgetreten sind, z. B. Knackgeräusche bei der Ausgabe oder unerwartete Audioinhalte. Möglicherweise sind Sie bereits an einer crbug.com-Diskussion beteiligt und ein Chrome-Entwickler hat Sie gebeten, „Tracing-Daten“ hochzuladen oder sich die Diagrammvisualisierung anzusehen.

Hier erfahren Sie, wie Sie die relevanten Informationen erhalten, damit wir das Problem nachvollziehen und das zugrunde liegende Problem beheben können.

Tools zur Analyse von Web Audio

Es gibt zwei Tools, die Ihnen bei der Analyse von Web Audio helfen: about://tracing und die WebAudio -Erweiterung in den Chrome-Entwicklertools.

Wann wird about://tracing verwendet?

Bei unerklärlichen „Fehlern“. Durch die Analyse der App mit den Tracing-Tools erhalten Sie folgende Informationen:

• Zeitabschnitte, die von bestimmten Funktionsaufrufen in verschiedenen Threads verbracht werden
• Timing von Audio-Callbacks in der Zeitachsenansicht

Normalerweise werden verpasste Audio-Callback-Fristen oder eine umfangreiche Garbage Collection angezeigt, die unerwartete Audiofehler verursachen kann. Diese Informationen sind hilfreich, um ein zugrunde liegendes Problem zu verstehen. Daher werden sie von Chromium-Entwicklern häufig angefordert, insbesondere wenn die lokale Reproduktion nicht möglich ist. Lesen Sie unsere allgemeinen Anweisungen zum Tracing.

Wann wird die Web Audio DevTools-Erweiterung verwendet?

Wenn Sie das Audiogramm visualisieren und die Leistung des Audio-Renderers in Echtzeit beobachten möchten. Das Audiogramm, ein Netzwerk von AudioNode-Objekten zum Generieren und Synthetisieren eines Audiostreams, ist oft komplex, aber die Graphtopologie ist standardmäßig undurchsichtig. Die Web Audio API bietet keine Funktionen zur Knoten-/Graph-Introspektion. Es gibt einige Änderungen im Diagramm und Sie hören nichts mehr. Dann ist es Zeit für das Debugging durch Zuhören. Das ist nie einfach und wird schwieriger, wenn Sie ein größeres Audiogramm haben. Die Web Audio DevTools-Erweiterung kann Ihnen helfen, indem sie das Diagramm visualisiert.

Mit dieser Erweiterung können Sie eine laufende Schätzung der Rendering-Kapazität beobachten, die angibt, wie der Web Audio-Renderer mit einem bestimmten Rendering-Budget umgeht (z. B. ca. 2, 67 ms bei 48 kHz). Wenn die Kapazität fast 100 % erreicht, bedeutet das, dass Ihre App wahrscheinlich Fehler verursacht, da der Renderer die Arbeit nicht innerhalb des vorgegebenen Budgets abschließen kann.

about://tracing verwenden

Schließen Sie alle anderen Tabs und Fenster und deaktivieren Sie Erweiterungen, um optimale Ergebnisse zu erzielen. Alternativ können Sie entweder eine neue Instanz von Chrome starten oder andere Builds aus verschiedenen Release-Kanälen verwenden (z.B. Beta oder Canary). Sobald der Browser bereit ist, gehen Sie so vor:

1. Öffnen Sie Ihre Anwendung (Webseite) auf einem Tab.
2. Öffnen Sie einen weiteren Tab und rufen Sie about://tracing auf.
3. Klicken Sie auf die Schaltfläche Aufzeichnen und wählen Sie Einstellungen manuell auswählen aus.
4. Klicken Sie in den Abschnitten Aufzeichnungskategorien und Standardmäßig deaktivierte Kategorien auf die Schaltfläche Keine.
5. Wählen Sie im Abschnitt Aufzeichnungskategorien Folgendes aus:
   • audio
   • blink_gc
   • media
   • v8.execute (wenn Sie sich für die Leistung des AudioWorklet-JS-Codes interessieren)
   • webaudio
6. Wählen Sie im Abschnitt Standardmäßig deaktivierte Kategorien Folgendes aus:
   • audio-worklet (wenn Sie wissen möchten, wo der AudioWorklet-Thread startet)
   • webaudio.audionode (wenn Sie die detaillierte Ablaufverfolgung für jedes AudioNode benötigen)
7. Klicken Sie unten auf die Schaltfläche Aufzeichnen.
8. Kehren Sie zum Tab mit Ihrer Anwendung zurück und wiederholen Sie die Schritte, die das Problem ausgelöst haben.
9. Wenn Sie genügend Tracing-Daten haben, kehren Sie zum Tab „Tracing“ zurück und klicken Sie auf Beenden.

10. Auf dem Tab „Tracing“ wird das Ergebnis visualisiert.

    

11. Klicken Sie auf Speichern , um die Tracing-Daten zu speichern.

Tracing-Daten analysieren

Die Tracing-Daten visualisieren, wie die Web Audio-Engine von Chrome die Audioinhalte rendert. Der Renderer hat zwei verschiedene Rendering-Modi: Betriebssystemmodus und Worklet-Modus. Jeder Modus verwendet ein anderes Threading-Modell, daher unterscheiden sich auch die Tracing-Ergebnisse.

Betriebssystemmodus

Im Betriebssystemmodus wird der gesamte Web Audio-Code im AudioOutputDevice Thread ausgeführt. AudioOutputDevice ist ein Thread mit Echtzeitpriorität, der vom Audio-Dienst des Browsers stammt und von der Audio-Hardwareuhr gesteuert wird. Wenn Sie in dieser Spur Unregelmäßigkeiten in den Tracing-Daten sehen, kann das Callback-Timing des Geräts unregelmäßig sein. Diese Kombination aus Linux und Pulse Audio ist dafür bekannt.

Weitere Informationen finden Sie in den folgenden Chromium-Problemen: #825823, #864463.

Worklet-Modus

Im Worklet-Modus, der durch einen Thread-Sprung von AudioOutputDevice zum AudioWorklet Thread gekennzeichnet ist, sollten Sie gut ausgerichtete Traces in zwei Thread-Spuren sehen. Wenn das Worklet aktiviert ist, werden alle Web Audio-Vorgänge vom AudioWorklet-Thread gerendert. Dieser Thread hat keine Echtzeitpriorität.

Die häufigste Unregelmäßigkeit ist ein großer Block, der durch die Garbage Collection oder verpasste Rendering-Fristen verursacht wird. Beide Fälle führen zu Fehlern im Audiostream.

In beiden Fällen zeichnen sich die idealen Tracing-Daten durch gut ausgerichtete Audio-Device-Callback-Aufrufe und Rendering-Aufgaben aus, die weit innerhalb des vorgegebenen Rendering-Budgets abgeschlossen werden. Die beiden Screenshots sind gute Beispiele für die idealen Tracing-Daten.

Aus Beispielen aus der Praxis lernen

Beispiel 1: Rendering-Aufgaben, die das Rendering-Budget überschreiten

Der Screenshot unten (Chromium-Problem #796330) ist ein typisches Beispiel dafür, dass Code in AudioWorkletProcessor zu lange dauert und ein vorgegebenes Rendering-Budget überschreitet. Das Callback-Timing ist gut, aber der Funktionsaufruf zur Audioverarbeitung der Web Audio API konnte die Arbeit nicht vor dem nächsten Geräte-Callback abschließen.

Ihre Optionen:

• Reduzieren Sie die Arbeitslast des Audiogramms, indem Sie weniger AudioNode-Instanzen verwenden.
• Reduzieren Sie die Arbeitslast Ihres Codes in AudioWorkletProcessor.
• Erhöhen Sie die Basis-Latenz von AudioContext.

Beispiel 2: Umfangreiche Garbage Collection im Worklet-Thread

Im Gegensatz zum Audio-Rendering-Thread des Betriebssystems wird die Garbage Collection im Worklet-Thread verwaltet. Wenn Ihr Code also Speicher zuweist oder freigibt (z.B. neue Arrays), wird dadurch eine Garbage Collection ausgelöst, die den Thread synchron blockiert. Wenn die Arbeitslast von Web Audio-Vorgängen und Garbage Collection größer als ein vorgegebenes Rendering-Budget ist, führt das zu Fehlern im Audiostream. Der folgende Screenshot ist ein extremes Beispiel für diesen Fall.

Ihre Optionen:

• Weisen Sie den Speicher im Voraus zu und verwenden Sie ihn nach Möglichkeit wieder.
• Verwenden Sie verschiedene Designmuster, die auf SharedArrayBuffer basieren. Das ist zwar keine perfekte Lösung, aber mehrere Web Audio-Apps verwenden ein ähnliches Muster mit SharedArrayBuffer, um den intensiven Audio-Code auszuführen. Beispiele:
  • Audio Worklet Design Pattern

Beispiel 3: Unregelmäßiges Audio-Device-Callback von AudioOutputDevice

Das genaue Timing von Audio-Callbacks ist das Wichtigste für Web Audio. Das sollte die genaueste Uhr in Ihrem System sein. Wenn das Betriebssystem oder sein Audio-Subsystem kein solides Callback-Timing garantieren kann, sind alle nachfolgenden Vorgänge betroffen. Die folgende Abbildung ist ein Beispiel für ein unregelmäßiges Audio-Callback. Im Vergleich zu den beiden vorherigen Abbildungen variiert das Intervall zwischen den einzelnen Callbacks erheblich.

Ihre Optionen:

• Erhöhen Sie die Größe des Audio-Callback-Puffers des Systems, indem Sie die latencyHint Option anpassen.
• Wenn Sie ein Problem finden, melden Sie es unter crbug.com und fügen Sie die Tracing-Daten bei.

Web Audio DevTools-Erweiterung verwenden

Sie können auch die DevTools-Erweiterung verwenden, die speziell für die Web Audio API entwickelt wurde. Im Gegensatz zum Tracing-Tool ermöglicht sie die Echtzeitprüfung von Diagrammen und Leistungsmesswerten.

Diese Erweiterung muss aus dem Chrome Web Store installiert werden.

Nach der Installation können Sie auf den Bereich zugreifen, indem Sie die Chrome-Entwicklertools öffnen und im oberen Menü auf „Web Audio“ klicken.

Der Bereich „Web Audio“ besteht aus vier Komponenten: Kontextauswahl, Eigenschafteninspektor, Diagrammvisualisierung und Leistungsüberwachung.

Kontextauswahl

Da eine Seite mehrere BaseAudioContext-Objekte haben kann, können Sie in diesem Drop-down-Menü den Kontext auswählen, den Sie prüfen möchten. Sie können die Garbage Collection auch manuell auslösen, indem Sie links auf das Papierkorbsymbol klicken.

Eigenschafteninspektor

Im Seitenbereich werden verschiedene Eigenschaften eines vom Nutzer ausgewählten Kontexts oder AudioNode angezeigt. Die Prüfung dynamischer Werte in AudioParam wird nicht unterstützt.

Diagrammvisualisierung

In dieser Ansicht wird die aktuelle Graphtopologie eines vom Nutzer ausgewählten Kontexts gerendert. Diese Visualisierung ändert sich dynamisch in Echtzeit. Wenn Sie auf ein Element in der Visualisierung klicken, können Sie die detaillierten Informationen im Eigenschafteninspektor prüfen.

Leistungsüberwachung

Die Statusleiste unten ist nur aktiv, wenn der ausgewählte BaseAudioContext ein AudioContextist, der in Echtzeit ausgeführt wird. In dieser Leiste wird die momentane Audiostreamqualität eines ausgewählten AudioContext angezeigt und jede Sekunde aktualisiert. Sie enthält folgende Informationen:

• Callback-Intervall (ms): Zeigt den gewichteten Mittelwert oder die Varianz des Callback-Intervalls an. Im Idealfall sollte der Mittelwert stabil und die Varianz nahe null sein. Wenn Sie eine große Varianz sehen, bedeutet das, dass die Audio-Callback-Funktion auf Systemebene ein instabiles Timing hat, was zu einer schlechten Audiostreamqualität führen kann. Siehe Beispiel 3.

• Rendering-Kapazität (%): Wenn die Kapazität fast 100 % erreicht, bedeutet das, dass der Renderer zu viel für ein bestimmtes Rendering-Budget leistet. Sie sollten daher weniger tun (z. B. weniger AudioNodes-Objekte im Diagramm verwenden).

Sie können die Garbage Collection manuell auslösen, indem Sie auf das Papierkorbsymbol klicken.

Älterer Bereich „WebAudio DevTools“

Die Erweiterung ist jetzt die empfohlene Methode des Chrome Web Audio-Teams, aber der ältere Bereich „WebAudio DevTools“ ist auch verfügbar. Sie können auf diesen Bereich zugreifen, indem Sie rechts oben in den Entwicklertools auf das Dreipunkt-Menü klicken und dann zu Weitere Tools > WebAudio gehen.

Fazit

Das Debugging von Audio ist schwierig. Das Debugging von Audio im Browser ist noch schwieriger. Diese Tools können Ihnen jedoch helfen, indem sie nützliche Informationen zur Leistung des Web Audio-Codes liefern. In einigen Fällen können jedoch Probleme in Chrome oder der Erweiterung auftreten. Melden Sie einen Fehler unter crbug.com oder im Issue Tracker der Erweiterung.