Profilerstellung für Web-Audio-Apps in Chrome

Informationen zum Erstellen von Leistungsprofilen für Web Audio-Apps in Chrome mit about://tracing und Audion (eine WebAudio-Erweiterung in den Chrome-Entwicklertools)

Hongchan Choi

Sie sind wahrscheinlich auf diesen Artikel gestoßen, weil Sie eine App entwickeln, in der die Web Audio API verwendet wird, und unerwartete Fehler wie Knacken aus der Ausgabe auftreten oder Sie etwas Unerwartetes hören. Möglicherweise sind Sie bereits an einer crbug.com-Diskussion beteiligt und ein Chrome-Entwickler hat Sie gebeten, „Tracing-Daten“ hochzuladen oder sich die Grafikvisualisierung anzusehen. In diesem Artikel wird beschrieben, wie du die relevanten Informationen bekommst, damit wir das Problem nachvollziehen und beheben können.

Web Audio-Profilierungstools

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

Wann verwenden Sie about://tracing?

Wenn mysteriöse „Glitches“ auftreten. Wenn Sie die App mit den Analysetools erfassen, erhalten Sie Informationen zu folgenden Punkten:

  • Zeitscheiben, die durch bestimmte Funktionsaufrufe in verschiedenen Threads verbracht wurden
  • Zeitpunkt des Rückrufs in der Zeitachse

In der Regel werden verpasste Fristen für Audio-Callback-Funktionen oder eine große Garbage Collection angezeigt, die zu unerwarteten Audio-Störungen führen können. Diese Informationen sind hilfreich, um ein zugrunde liegendes Problem zu verstehen. Chromium-Entwickler stellen diese Frage daher häufig, insbesondere wenn eine lokale Reproduktion nicht möglich ist. Eine allgemeine Anleitung zum Nachverfolgen findest du hier.

Wann verwenden Sie die Web Audio DevTools-Erweiterung?

Wenn Sie die Audiografik visualisieren und die Leistung des Audio-Renderers in Echtzeit beobachten möchten. Der Audiograph, ein Netzwerk von AudioNode-Objekten zum Generieren und Synthetisieren eines Audiostreams, wird oft komplex, aber die Graphtopologie ist von Natur aus undurchsichtig. Die Web Audio API bietet keine Funktionen für die Knoten-/Graph-Inspektion. Es gibt einige Änderungen in Ihrem Diagramm und jetzt hören Sie nur noch Stille. Jetzt ist es an der Zeit, das Problem zu beheben, indem Sie zuhören. Das ist nie einfach und wird noch schwieriger, wenn du einen größeren Audio-Graphen hast. Die Web Audio DevTools-Erweiterung kann Ihnen dabei helfen, das Diagramm zu visualisieren.

Mit dieser Erweiterung können Sie eine aktuelle Schätzung der Renderkapazität beobachten, die angibt, wie der Web-Audio-Renderer bei einem bestimmten Renderbudget abschneidet (z. B. etwa 2,67 ms bei 48 kHz). Wenn die Kapazität fast 100 % erreicht, kommt es in Ihrer App wahrscheinlich zu Rucklern, da der Renderer die Arbeit nicht im vorgegebenen Budget abschließen kann.

about://tracing“ verwenden

Aufrufdaten erfassen

Die folgende Anleitung gilt für Chrome 80 und höher.

Die besten Ergebnisse erzielen Sie, wenn Sie alle anderen Tabs und Fenster schließen und Erweiterungen deaktivieren. 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 geöffnet ist, gehen Sie so vor:

  1. Öffnen Sie die Anwendung (Webseite) in einem Tab.
  2. Öffnen Sie einen neuen Tab und rufen Sie about://tracing auf.
  3. Drücken Sie die Schaltfläche Aufzeichnen und wählen Sie Einstellungen manuell auswählen aus.
  4. Drücken Sie sowohl im Bereich Eintragskategorien als auch im Bereich Standardmäßig deaktivierte Kategorien die Schaltfläche Keine.
  5. Wählen Sie im Bereich Eintragskategorien die folgenden Optionen aus:
    • audio
    • blink_gc
    • media
    • v8.execute (für Informationen zur AudioWorklet JS-Codeleistung)
    • webaudio
  6. Wählen Sie im Bereich Standardmäßig deaktivierte Kategorien Folgendes aus:
    • audio-worklet (wenn Sie wissen möchten, wo der AudioWorklet-Thread beginnt)
    • webaudio.audionode (wenn Sie den detaillierten Trace für jede AudioNode benötigen)
  7. Drücken Sie unten auf die Schaltfläche Aufzeichnen.
  8. Kehren Sie zum Tab „Anwendung“ zurück und wiederholen Sie die Schritte, die das Problem ausgelöst haben.
  9. Wenn Sie genügend Daten erfasst haben, kehren Sie zum Tab „Tracing“ zurück und klicken Sie auf Beenden.
  10. Auf dem Tab „Tracing“ wird das Ergebnis visualisiert.

    Screenshot nach Abschluss des Tracings

  11. Drücken Sie auf Speichern, um die Daten zu speichern.

Analyse von Tracking-Daten

Die Analysedaten zeigen, wie die Audiodaten von der Web-Audio-Engine von Chrome gerendert werden. Der Renderer hat zwei verschiedene Rendering-Modi: Betriebssystemmodus und Worklet-Modus. Für jeden Modus wird ein anderes Threading-Modell verwendet, sodass sich die Ergebnisse der Aufrufabfolgen unterscheiden.

Betriebssystemmodus

Im Betriebssystemmodus wird der gesamte Web-Audiocode vom Thread AudioOutputDevice ausgeführt. Der AudioOutputDevice ist ein Echtzeit-Prioritäts-Thread, der vom Audiodienst des Browsers stammt und von der Audio-Hardwareuhr gesteuert wird. Wenn Sie Unregelmäßigkeiten in den Trace-Daten in dieser Spur sehen, ist das Callback-Timing des Geräts möglicherweise unregelmäßig. Bei der Kombination von Linux und Pulse Audio ist dieses Problem bekannt. Weitere Informationen finden Sie in den folgenden Chromium-Problemen: #825823, #864463.

Screenshot des Ergebnisses der Betriebssystemmodus-Analyse

Worklet-Modus

Im Worklet-Modus, der durch einen Threadsprung von AudioOutputDevice zum AudioWorklet-Thread gekennzeichnet ist, sollten Sie gut ausgerichtete Spuren in zwei Thread-Bahnen sehen, wie unten dargestellt. Wenn das Worklet aktiviert ist, werden alle Web-Audio-Vorgänge vom AudioWorklet-Thread gerendert. Dieser Thread hat derzeit keine Priorität in Echtzeit. Die häufigste Anomalie ist ein großer Block, der durch die automatische Speicherbereinigung oder verpasste Rendering-Frist verursacht wird. In beiden Fällen kommt es zu Störungen im Audiostream.

Screenshot des Ergebnisses der Ablaufverfolgung im Worklet-Modus

In beiden Fällen zeichnen sich die idealen Tracing-Daten durch gut ausgerichtete Callback-Aufrufe von Audiogeräten und Renderaufgaben aus, die weit innerhalb des angegebenen Renderbudgets abgeschlossen werden. Die beiden Screenshots oben sind gute Beispiele für ideale Daten zum Nachverfolgen.

Von Beispielen aus der Praxis lernen

Beispiel 1: Renderaufgaben, die das Renderbudget überschreiten

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

Diagramm mit Audiofehlern aufgrund eines Budgetüberschreitungsfehlers bei der Renderaufgabe

Mögliche Optionen:

  • Verringern Sie die Arbeitslast des Audio-Graphs, indem Sie weniger AudioNode-Instanzen verwenden.
  • Reduzieren Sie die Arbeitslast Ihres Codes in der AudioWorkletProcessor.
  • Erhöhen Sie die Basislatenz auf AudioContext.

Beispiel 2: Intensive Garbage Collection im Worklet-Thread

Anders als im Audio-Rendering-Thread des Betriebssystems wird die Garbage Collection im Worklet-Thread verwaltet. Das bedeutet, dass bei der Speicherzuweisung/-entfernung (z.B. bei neuen Arrays) in Ihrem Code irgendwann eine Garbage Collection ausgelöst wird, die den Thread synchron blockiert. Wenn die Arbeitslast der Web-Audio-Vorgänge und der Garbage Collection größer als ein bestimmtes Rendering-Budget ist, kommt es zu Störungen im Audiostream. Der folgende Screenshot ist ein extremes Beispiel für diesen Fall.

Audiostörungen, die durch die automatische Speicherbereinigung verursacht werden.

Mögliche Optionen:

  • Weisen Sie den Arbeitsspeicher vorab zu und verwenden Sie ihn nach Möglichkeit wieder.
  • Verwenden Sie verschiedene Designmuster, die auf SharedArrayBuffer basieren. Obwohl dies keine perfekte Lösung ist, verwenden mehrere Web-Audio-Apps ein ähnliches Muster mit SharedArrayBuffer, um den intensiven Audiocode auszuführen. Beispiele:

Beispiel 3: Ruckelnder Callback des Audiogeräts von AudioOutputDevice

Das genaue Timing des Audio-Callbacks ist für Web Audio am wichtigsten. Dies sollte die genaueste Uhr in Ihrem System sein. Wenn das Betriebssystem oder sein Audio-Subsystem kein zuverlässiges Callback-Timing garantieren kann, sind alle nachfolgenden Vorgänge betroffen. Das folgende Bild zeigt ein Beispiel für einen Audio-Callback mit Jitter. Im Vergleich zu den beiden vorherigen Bildern variiert das Intervall zwischen den einzelnen Rückrufen erheblich.

Screenshot, in dem das Timing von instabilen und stabilen Rückrufen verglichen wird

Mögliche Optionen:

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 Trace-Tool können Sie hier Grafiken und Leistungsmesswerte in Echtzeit prüfen.

Diese Erweiterung muss aus dem Chrome Web Store installiert werden.

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

Screenshot, der zeigt, wie das Web Audio-Steuerfeld in den Chrome-Entwicklertools geöffnet wird

Der Bereich „Web Audio“ besteht aus vier Komponenten: Kontextauswahl, Property-Inspektor, Diagrammvisualisierung und Leistungsmonitor.

Screenshot des Web Audio-Steuerfelds in den Chrome-Entwicklertools

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 Müllabfuhr auch manuell auslösen, indem Sie links auf das Mülleimersymbol klicken.

Property Inspector

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 Graphentopologie 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 Details im Property Inspector prüfen.

Leistungsüberwachung

Die Statusleiste unten ist nur aktiv, wenn die ausgewählte BaseAudioContext eine AudioContext ist, die in Echtzeit ausgeführt wird. Dieser Balken zeigt die aktuelle Audiostreamqualität einer ausgewählten AudioContext an und wird jede Sekunde aktualisiert. Sie enthält die folgenden Informationen:

  • Callback-Intervall (ms): Der gewichtete Mittelwert/die gewichtete Abweichung des Callback-Intervalls. Idealerweise sollte der Mittelwert stabil sein und die Varianz nahe bei Null liegen. Wenn die Abweichung groß ist, 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 oben.)

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

Sie können einen Garbage Collector manuell auslösen, indem Sie auf das Papierkorbsymbol klicken.

Legacy WebAudio DevTools-Bereich

Die Erweiterung wird jetzt vom Chrome Web Audio-Team empfohlen. Das WebAudio-Steuerfeld in den DevTools ist jedoch weiterhin verfügbar. Sie können auf diesen Bereich zugreifen, indem Sie rechts oben in den Entwicklertools auf das Dreipunkt-Menü klicken, dann Weitere Tools und dann WebAudio auswählen.

Screenshot, der zeigt, wie der WebAudio-Bereich in den Chrome-Entwicklertools geöffnet wird

Fazit

Das Beheben von Audioproblemen ist schwierig. Das Debugging von Audio im Browser ist noch schwieriger. Diese Tools können Ihnen jedoch helfen, da sie nützliche Informationen zur Leistung des Web-Audiocodes liefern. In einigen Fällen können jedoch Probleme mit Chrome oder der Erweiterung auftreten. Dann zögern Sie nicht, einen Fehler auf crbug.com oder im Issue Tracker für Erweiterungen zu melden.

Foto von Jonathan Velasquez auf Unsplash