Profilazione delle app web Audio in Chrome

Scopri come profilare le prestazioni delle app web audio in Chrome utilizzando about://tracing e Audion (un'estensione WebAudio in Chrome DevTools).

Hai consultato questo articolo probabilmente perché stai sviluppando un'app che utilizza l'API Web Audio e hai riscontrato glitch imprevisti, come rumori di schiocco dall'output, o perché senti qualcosa di inaspettato. Potresti aver già partecipato a una discussione su crbug.com e un ingegnere di Chrome ti ha chiesto di caricare "dati di tracciamento" o di esaminare la visualizzazione del grafico. Questo articolo mostra come ottenere le informazioni pertinenti per consentirci di comprendere un problema e, infine, di risolverlo.

Strumenti di profilazione dell'audio web

Esistono due strumenti che ti consentono di eseguire la profilazione dell'audio web: about://tracing e l'estensione WebAudio in Chrome DevTools.

Quando usi about://tracing?

Quando si verificano misteriosi "glitch". La profilazione dell'app con gli strumenti di tracciamento offre insight su:

• Sezioni di tempo utilizzate da chiamate di funzione specifiche in thread diversi
• Tempistiche della callback audio nella visualizzazione cronologica

Di solito mostra scadenze non rispettate per il callback audio o grandi garbage collection che potrebbero causare problemi audio imprevisti. Queste informazioni sono utili per comprendere un problema di fondo, pertanto gli ingegneri di Chromium lo chiedono spesso, soprattutto quando la riproduzione locale non è fattibile. Le istruzioni generali per il tracciamento sono disponibili qui.

Quando utilizzi l'estensione Web Audio DevTools?

Per visualizzare il grafico audio e monitorare le prestazioni del renderer 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 definizione. (L'API Web Audio non ha funzionalità per introspezione di nodi/grafici.) Nel grafico vengono apportate alcune modifiche e ora senti il silenzio. Poi è il momento di eseguire il debug mediante l'ascolto. Non è mai facile e diventa più difficile con un grafico audio più grande. L'estensione Web Audio DevTools può aiutarti visualizzando il grafico.

Con questa estensione puoi monitorare una stima in esecuzione della capacità di rendering, che indica le prestazioni del renderer audio web rispetto a un determinato budget di rendering (ad esempio, circa 2,67 ms a 48 KHz). Se la capacità si avvicina al 100%, è probabile che la tua app generi glitch perché il renderer non riesce a terminare il lavoro nei limiti del budget stabilito.

Formato about://tracing

Come acquisire dati di tracciamento

Le istruzioni riportate di seguito riguardano Chrome 80 e versioni successive.

Per ottenere 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 da diversi canali di rilascio (ad es. beta o Canary). Quando il browser è pronto, procedi nel seguente modo:

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 Nessuno in entrambe le sezioni Categorie di record e Disabilitati per categorie predefinite.
5. Nella sezione Record categorie, seleziona quanto segue:
   • audio
   • blink_gc
   • media
   • v8.execute (se ti interessa il rendimento del codice JS AudioWorklet)
   • webaudio
6. Nella sezione Disattivato da categorie predefinite, seleziona quanto segue:
   • audio-worklet (se ti interessa sapere da dove inizia il thread AudioWorklet)
   • webaudio.audionode (se ti serve la 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 disponi di dati di traccia sufficienti, torna alla scheda di tracciamento e premi Interrompi.

10. La scheda Tracciamento mostrerà il risultato.

    

11. Premi Salva per salvare i dati di tracciamento.

Come analizzare i dati di tracciamento

I dati di tracciamento mostrano in che modo 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, quindi anche i risultati di tracciamento sono diversi.

Modalità 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 controllato dall'orologio hardware audio. Se noti un'irregolarità nei dati di traccia in questa corsia, significa che il tempo di callback del dispositivo potrebbe essere tremolante. È noto che la combinazione di Linux e Pulse Audio presenta questo problema. Per maggiori dettagli, consulta i seguenti problemi di Chromium: #825823, #864463.

Modalità di lavoro

In modalità di lavoro, caratterizzata da un salto di un thread da AudioOutputDevice al thread AudioWorklet, dovresti vedere tracce ben allineate in due corsie di thread, come mostrato di seguito. Quando il worklet viene attivato, tutte le operazioni audio web vengono visualizzate dal thread AudioWorklet. Questo thread al momento non è una priorità in tempo reale. L'irregolarità comune in questo caso è un blocco di grandi dimensioni causata dalla garbage collection o dal mancato rispetto di scadenze di rendering. Entrambi i casi causano glitch nello stream audio.

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

Imparare da esempi reali

Esempio 1: eseguire il rendering delle attività che vanno oltre il budget di rendering

Il seguente screenshot (problema di Chromium n. 796330) è un tipico esempio di quando il codice in AudioWorkletProcessor richiede troppo tempo e va oltre un determinato budget di rendering. La tempistica del callback è corretta, ma la chiamata della funzione di elaborazione audio dell'API Web Audio non è riuscita a completare il lavoro prima del successivo callback del dispositivo.

Opzioni a tua disposizione:

• 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: garbage collection significativa nel thread di worklet

A differenza del thread di rendering audio del sistema operativo, la garbage collection viene gestita nel thread di worklet. Ciò significa che se il codice esegue allocazione della memoria/deallocation (ad esempio nuovi array), alla fine attiva una garbage collection che blocca in modo sincrono il thread. Se il carico di lavoro per le operazioni audio sul web e la garbage collection supera un determinato budget di rendering, si verificano degli errori nello stream audio. Lo screenshot seguente è un esempio estremo di questo caso.

Opzioni a tua disposizione:

• Alloca la memoria in anticipo e riutilizzala quando possibile.
• Utilizza pattern di progettazione diversi basati su SharedArrayBuffer. Sebbene questa non sia la soluzione perfetta, diverse app audio web utilizzano un pattern simile con SharedArrayBuffer per eseguire il codice audio ad alto utilizzo. Esempi:
  • Pattern di progettazione del worklet per l'audio

Esempio 3: callback del dispositivo audio Jittery da AudioOutputDevice

La tempistica esatta del callback audio è la cosa più importante per l'audio web. Dovrebbe essere l'orologio più preciso del tuo sistema. Se il sistema operativo o il relativo sottosistema audio non sono in grado di garantire una buona tempistica di callback, tutte le operazioni successive saranno interessate. L'immagine seguente è un esempio di callback audio tremolante. Rispetto alle due immagini precedenti, l'intervallo tra ogni callback varia in modo significativo.

Opzioni a tua disposizione:

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

Utilizzare l'estensione Web Audio DevTools

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

Questa estensione deve essere installata dal Chrome Web Store.

Dopo l'installazione, per accedere al riquadro apri Chrome DevTools e fai clic su "Web Audio" nel menu in alto.

Il riquadro Audio web ha quattro componenti: selettore di contesto, strumento di controllo delle proprietà, visualizzatore di grafici e monitoraggio delle prestazioni.

Selettore del contesto

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

Controllo proprietà

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

Visualizzatore grafico

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

Monitoraggio delle prestazioni

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

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

• Capacità di rendering (percentuale): se la capacità si avvicina al 100%, significa che il renderer sta facendo troppo per un determinato budget di rendering, quindi dovresti valutare la possibilità di fare di meno (ad esempio utilizzando meno oggetti AudioNodes nel grafico).

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

Riquadro WebAudio DevTools precedente

Ora l'estensione è un metodo consigliato dal team di Chrome Web Audio, ma è disponibile anche il riquadro WebAudio DevTools precedente. Puoi accedere a questo riquadro facendo clic sul menu con tre puntini nell'angolo in alto a destra di DevTools, quindi selezionando Altri strumenti e infine WebAudio.

Conclusione

Il debug dell'audio è difficile. Il debug dell'audio nel browser è ancora più difficile. Tuttavia, questi strumenti possono alleviare il problema, fornendo insight utili sulle prestazioni del codice audio web. In alcuni casi, tuttavia, potresti riscontrare problemi in Chrome o nell'estensione. Dopodiché, non avere paura di segnalare un bug su crbug.com o nel tracker dei problemi delle estensioni.

Foto di Jonathan Velasquez su Unsplash