Profilazione delle app web Audio in Chrome

Scopri come eseguire il profiling delle prestazioni delle app Web Audio in Chrome utilizzando about://tracing e Audion (un'estensione WebAudio in Chrome DevTools).

Probabilmente hai raggiunto questo articolo perché stai sviluppando un'app che utilizza l'API Web Audio e hai riscontrato glitch imprevisti, ad esempio rumori di scoppiettii dall'output o senti qualcosa di inaspettato. Potresti già essere coinvolto in una discussione su crbug.com e un ingegnere di Chrome potrebbe averti chiesto di caricare "dati di monitoraggio" o di esaminare la visualizzazione del grafico. Questo articolo illustra come ottenere le informazioni pertinenti per consentirci di comprendere un problema e, eventualmente, risolverlo.

Strumenti di profilazione di Web Audio

Esistono due strumenti che ti aiuteranno a eseguire il profiling di Web Audio,about://tracing e l'estensione WebAudio in Chrome DevTools.

Quando utilizzi about://tracing?

Quando si verificano "glitch" misteriosi. La profilazione dell'app con gli strumenti di monitoraggio ti fornisce informazioni su:

• Slicchi di tempo spesi da chiamate di funzioni specifiche in thread diversi
• Tempi di richiamata audio nella visualizzazione della cronologia

Di solito vengono mostrate scadenze per i callback audio perse o una raccolta dei rifiuti di grandi dimensioni che potrebbe causare glitch audio imprevisti. Queste informazioni sono utili per comprendere un problema sottostante, pertanto gli ingegneri di Chromium le chiederanno spesso, soprattutto quando la riproduzione locale non è fattibile. Le istruzioni generali per il monitoraggio sono disponibili qui.

Quando utilizzare l'estensione DevTools per Web Audio?

Quando vuoi visualizzare il grafico audio e monitorare il funzionamento del visualizzatore audio in tempo reale. Il grafico audio, una rete di oggetti AudioNode per generare e sintetizzare uno stream audio, spesso diventa complesso, ma la topologia del grafico è opaca per progettazione. L'API Web Audio non dispone di funzionalità per l'introspezione di nodi/grafi. Nel grafico si verificano alcune variazioni e ora non senti più nulla. A questo punto è il momento di eseguire il debug ascoltando. Non è mai facile e diventa più difficile quando hai un grafico audio più grande. L'estensione DevTools Web Audio può aiutarti visualizzando il grafico.

Con questa estensione puoi monitorare una stima in tempo reale della capacità di rendering, che indica il rendimento del renderer audio web in base a un determinato budget di rendering (ad es. circa 2,67 ms a 48 KHz). Se la capacità si avvicina al 100%, significa che la tua app potrebbe produrre glitch perché il renderer non riesce a completare il lavoro nel budget specificato.

Utilizza about://tracing

Come acquisire i dati di monitoraggio

Le istruzioni riportate di seguito si riferiscono a Chrome 80 e versioni successive.

Per risultati ottimali, chiudi tutte le altre schede e finestre e disattiva le estensioni. In alternativa, puoi avviare una nuova istanza di Chrome o utilizzare altre build di canali di rilascio diversi (ad es. beta o Canary). Una volta pronto il browser, segui questi passaggi:

1. Apri l'applicazione (pagina web) in una scheda.
2. Apri un'altra scheda e vai a about://tracing.
3. Premi il pulsante Registra e seleziona Seleziona manualmente le impostazioni.
4. Premi i pulsanti Nessuna sia nelle sezioni Categorie di record sia Categorie disattivate per impostazione predefinita.
5. Nella sezione Categorie di record, seleziona quanto segue:
   • audio
   • blink_gc
   • media
   • v8.execute (se ti interessa il rendimento del codice JS AudioWorklet)
   • webaudio
6. Nella sezione Categorie disattivate per impostazione predefinita, seleziona quanto segue:
   • audio-worklet (se ti interessa dove inizia il thread AudioWorklet)
   • webaudio.audionode (se hai bisogno della traccia dettagliata per ogni AudioNode)
7. Premi il pulsante Registra in basso.
8. Torna alla scheda dell'applicazione e ripeti i passaggi che hanno attivato il problema.
9. Quando hai raccolto dati di traccia sufficienti, torna alla scheda di monitoraggio e premi Interrompi.

10. La scheda Traccia visualizza il risultato.

    

11. Premi Salva per salvare i dati del rilevamento.

Come analizzare i dati di monitoraggio

I dati di tracciamento mostrano come il motore audio web di Chrome esegue il rendering dell'audio. Il renderer ha due diverse modalità di rendering: Modalità Sistema operativo e Modalità Worklet. Ogni modalità utilizza un modello di threading diverso, pertanto anche i risultati del monitoraggio differiscono.

Modalità del sistema operativo

In modalità sistema operativo, il thread AudioOutputDevice esegue tutto il codice audio web. AudioOutputDevice è un thread con priorità in tempo reale proveniente dal servizio audio del browser e basato sull'orologio hardware audio. Se noti irregolarità nei dati della traccia in questa corsia, significa che la temporizzazione del callback dal dispositivo potrebbe essere instabile. È noto che la combinazione di Linux e Pulse Audio presenta questo problema. Per ulteriori dettagli, consulta i seguenti problemi di Chromium: #825823, #864463.

Modalità worklet

In modalità Worklet, che è caratterizzata da un salto di thread daAudioOutputDevice al thread AudioWorklet, dovresti vedere tracce ben allineate in due corsie di thread, come mostrato di seguito. Quando il worklet è attivato, tutte le operazioni audio web vengono visualizzate dal thread AudioWorklet. Al momento questo thread non è una priorità in tempo reale. L'irregolarità più comune è un blocco di grandi dimensioni causato dalla raccolta del garbage o dalla mancata scadenza del rendering. Entrambi i casi causano glitch nello stream audio.

In entrambi i casi, i dati di tracciamento ideali sono caratterizzati da chiamate di callback del dispositivo audio ben allineate e da attività di rendering completate ampiamente entro il budget di rendering specificato. I due screenshot sopra sono ottimi esempi di dati di monitoraggio ideali.

Apprendimento da esempi reali

Esempio 1: attività di rendering che superano il budget di rendering

Lo screenshot seguente (Chromium issue #796330) è un esempio tipico di quando il codice in AudioWorkletProcessor richiede troppo tempo e supera un determinato budget di rendering. La temporizzazione del callback è corretta, ma la chiamata alla funzione di elaborazione audio dell'API Web Audio non è riuscita a completare il lavoro prima del successivo callback del dispositivo.

Le opzioni disponibili sono:

• Riduci il carico di lavoro del grafico audio utilizzando meno istanze AudioNode.
• Riduci il carico di lavoro del codice in AudioWorkletProcessor.
• Aumenta la latenza di base di AudioContext.

Esempio 2: raccolta dei rifiuti significativa nel thread del worklet

A differenza del thread di rendering audio del sistema operativo, la raccolta dei rifiuti viene gestita sul thread del worklet. Ciò significa che se il codice esegue l'allocazione/deallocazione della memoria (ad es. nuovi array), alla fine attiva una raccolta dei rifiuti che blocca in modo sincrono il thread. Se il carico di lavoro delle operazioni audio web e della raccolta dei rifiuti è superiore a un determinato budget di rendering, si verificano glitch nello stream audio. Lo screenshot seguente è un esempio estremo di questo caso.

Le opzioni disponibili sono:

• Alloca la memoria in anticipo e riutilizzala quando possibile.
• Utilizza diversi pattern di progettazione in base a SharedArrayBuffer. Sebbene non sia una soluzione perfetta, diverse app audio web utilizzano un pattern simile con SharedArrayBuffer per eseguire il codice audio intensivo. Esempi:
  • Pattern di design dei worklet audio

Esempio 3: callback del dispositivo audio con jitter da AudioOutputDevice

La temporizzazione precisa del callback audio è la cosa più importante per l'audio web. Dovrebbe essere l'orologio più preciso del sistema. Se il sistema operativo o il relativo sottosistema audio non può garantire un timing solido dei rilanci, tutte le operazioni successive saranno interessate. L'immagine seguente è un esempio di callback audio con jitter. Rispetto alle due immagini precedenti, l'intervallo tra ogni chiamata di callback varia notevolmente.

Le opzioni disponibili sono:

• Aumenta la dimensione del buffer di callback dell'audio di sistema modificando l'opzione latencyHint.
• Se riscontri un problema, invia una segnalazione su crbug.com con i dati di tracciamento.

Utilizzare l'estensione DevTools Web Audio

Puoi anche utilizzare l'estensione DevTools progettata appositamente per l'API Web Audio. A differenza dello strumento di monitoraggio, questo consente di ispezionare in tempo reale i grafici e le metriche sul rendimento.

Questa estensione deve essere installata dal Chrome Web Store.

Dopo l'installazione, accedi al riquadro aprendo Chrome DevTools e facendo clic su "Web Audio" nel menu in alto.

Il riquadro Web Audio ha quattro componenti: selettore di contesto, ispezione proprietà, visualizzatore grafico e monitoraggio del rendimento.

Selettore del contesto

Poiché una pagina può avere più oggetti BaseAudioContext, questo menu a discesa ti consente di scegliere il contesto da ispezionare. Puoi anche attivare manualmente la raccolta immondizia facendo clic sull'icona del cestino a sinistra.

Property Inspector

Il riquadro laterale mostra varie proprietà di un contesto selezionato dall'utente o di AudioNode. L'ispezione dei valori dinamici in AudioParam non è supportata.

Visualizzatore di grafici

Questa visualizzazione mostra la topologia del grafico corrente di un contesto selezionato dall'utente. Questa visualizzazione cambia in modo dinamico in tempo reale. Se fai clic su un elemento nella visualizzazione, puoi esaminare le informazioni dettagliate nell'ispettore delle proprietà.

Monitoraggio delle prestazioni

La barra di stato in basso è attiva solo quando il BaseAudioContext selezionato è un AudioContext, che viene eseguito in tempo reale. Questa barra mostra la qualità istantanea dello stream audio di un AudioContext selezionato e viene aggiornata ogni secondo. Fornisce le seguenti informazioni:

• Intervallo di richiamata (ms): mostra la media/varianza ponderata dell'intervallo di richiamata. Idealmente, la media deve essere stabile e la varianza deve essere vicina a zero. Se noti una varianza elevata, significa che la funzione di callback audio a livello di sistema ha un timing instabile che può portare a una scarsa qualità dello stream audio. (vedi esempio 3 sopra).

• Capacità di rendering (in percentuale): quando la capacità si avvicina al 100%, significa che il renderer sta facendo troppo per un determinato budget di rendering, quindi ti consigliamo di fare di meno (ad es. utilizzare meno oggetti AudioNodes nel grafico).

Puoi attivare manualmente un garbage collector facendo clic sull'icona del cestino.

Riquadro DevTools WebAudio legacy

L'estensione è ora un metodo consigliato dal team di Chrome Web Audio, ma è disponibile anche il pannello DevTools WebAudio precedente. Per accedere a questo riquadro, fai clic sul menu "tre puntini" nell'angolo in alto a destra di DevTools, poi vai a Altri strumenti e infine a WebAudio.

Conclusione

Il debug dell'audio è difficile. Il debug dell'audio nel browser è ancora più difficile. Tuttavia, questi strumenti possono semplificare il compito fornendo approfondimenti utili sul funzionamento del codice audio web. In alcuni casi, però, potresti riscontrare problemi in Chrome o nell'estensione. In questo caso, non esitare a segnalare un bug su crbug.com o nel tracker dei problemi delle estensioni.

Foto di Jonathan Velasquez su Unsplash