Perché l'audio si interrompe anche con un uso della CPU basso? — Ragionare su buffer e scadenze

State ascoltando musica e ogni tanto il suono si interrompe con un «clic». In Gestione attività l’uso della CPU si aggira intorno al 10%, eppure è solo l’audio a non essere stabile. In casi come questo, perché l’audio si interrompe anche se la CPU ha margine?

Anche con un uso della CPU basso, l’audio può interrompersi se il rifornimento dei dati audio successivi non rispetta la scadenza. Il motivo è che i dati successivi devono essere consegnati mentre viene riprodotto l’audio rimasto nel buffer. Un rifornimento in ritardo a causa di attese su dati o lock, o di DPC/ISR sulla CPU logica necessaria, può verificarsi anche senza esaurire la capacità complessiva della CPU. Exclusive-Mode Streams, CPU Analysis

Tuttavia, il solo «clic» che si sente non basta per concludere che si tratti di un underrun. Sintomi simili possono derivare anche dalla sorgente audio, dall’applicazione, dagli effetti audio, dal dispositivo di uscita e così via. Per prima cosa si confronta, con la stessa sorgente, cambiando una condizione alla volta e poi ripristinandola; se così non si riesce a restringere il campo, si registra ciò che accade prima e dopo l’interruzione. Fix distorted or crackling audio in Windows

Questo articolo affronta quella domanda e quelle che ne seguono: «basta ingrandire il buffer?» e «che cosa bisogna confrontare e che cosa registrare per restringere le cause?». Non pretende di stabilire la causa di un singolo guasto in base al solo uso della CPU o a ciò che si sente.

L’ambito è principalmente l’uscita audio su Windows 11. Si confrontano uscite integrate, cablate, USB, Bluetooth e simili; per i software di produzione musicale (DAW) si tratta anche il confronto nei casi in cui l’applicazione o il driver offrono un’impostazione del buffer. Non vengono trattate in modo esaustivo la progettazione dell’intera catena di registrazione né la diagnosi delle comunicazioni wireless di ciascun dispositivo.

Nella spiegazione si usa come esempio di base la modalità condivisa. Il percorso effettivo, la quantità di buffer e il periodo di elaborazione variano a seconda di applicazione, API, driver e dispositivo, e non esiste una schermata di impostazione del buffer comune a tutte le applicazioni. Low Latency Audio

L’uso della CPU, i 10 millisecondi di audio residuo, gli istanti di rifornimento e gli altri valori citati qui sono ipotesi a scopo illustrativo. Non sono il resoconto di misurazioni che abbiano riprodotto il problema o rilevato un miglioramento su un PC specifico. Le operazioni della seconda parte sono procedure di verifica da eseguire nel vostro ambiente.

Il meccanismo si può leggere in ordine a partire dalla prossima sezione, «Buffer di riproduzione audio». Le operazioni per indagare sulle interruzioni si trovano in «Confrontare le condizioni di comparsa» e in «Registrare le interruzioni con WPR».

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 5, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

Buffer di riproduzione audio

Salvare un file musicale non basta a far suonare gli altoparlanti. L’applicazione prepara i dati audio e li consegna al dispositivo di uscita passando per Windows e per il driver. Il buffer di riproduzione audio è un’area in cui si accumulano temporaneamente i dati che verranno riprodotti subito dopo. Mentre il dispositivo riproduce i dati correnti, il lato che fornisce i dati prepara i successivi e li rifornisce. Rendering a Stream

flowchart TB
    accTitle: Accumulare un po' di audio in anticipo e poi riprodurlo
    accDescr: Il flusso in cui i dati audio preparati vengono riforniti al buffer e, mentre la riproduzione sul dispositivo procede, si preparano i dati successivi.
    A["Preparare l'audio successivo"] --> B["Rifornire il buffer"]
    B --> C["Riprodurre l'audio accumulato"]
    C -.->|"Prima che si esaurisca"| A

Figura 1: Perché la riproduzione continui, il rifornimento deve tenere il passo con il lato che consuma l’audio.

La figura 1 è uno schema concettuale che mostra soltanto il rapporto tra rifornimento e consumo. Non rappresenta i vari buffer presenti nel percorso audio reale come se fossero fisicamente un’unica area. Low Latency Audio

Il compito del buffer è assorbire i brevi sfasamenti temporali tra chi prepara l’audio e chi lo consuma, per ottenere una riproduzione continua. La capacità del buffer, però, è una cosa diversa dalla quantità di dati non ancora riprodotti che contiene in quel momento. «Ha una capacità di 10 millisecondi» non significa che restino sempre 10 millisecondi di audio. Rendering a Stream

Qui chiamiamo scadenza di rifornimento il vincolo temporale per cui i dati successivi necessari devono arrivare prima che quelli in riproduzione si esauriscano. L’elaborazione audio deve essere «pronta entro l’istante in cui deve suonare». «Alla fine il calcolo è stato completato» non basta. Lo stato in cui la fornitura non arriva in tempo e i dati da riprodurre si esauriscono è l’underrun, che porta a interruzioni e clic. Anche se i dati arrivano in ritardo, non si può riempire a posteriori un’interruzione che si è già sentita. Exclusive-Mode Streams

Il percorso dei dati audio

Nella normale modalità condivisa, il motore audio di Windows riceve i dati preparati dall’applicazione di riproduzione, mescola più suoni o applica effetti, e poi li passa al driver e al dispositivo di uscita. L’applicazione di riproduzione si occupa sia della lettura della sorgente sia della fornitura verso la destinazione di uscita, mentre il driver e il dispositivo di uscita trasportano i dati verso il dispositivo e li riproducono. Low Latency Audio

flowchart TB
    accTitle: Il percorso dei dati audio in modalità condivisa
    accDescr: Il motore audio mescola e applica effetti ai dati preparati dall'applicazione di riproduzione e li passa al driver; il dispositivo di uscita li riproduce.
    A["App di riproduzione: prepara i dati"] --> E["Motore audio: mix ed effetti"]
    E --> D["Driver: trasporta al dispositivo"]
    D --> O["Dispositivo di uscita: riproduce"]

Figura 2: Esempio in modalità condivisa. Le elaborazioni e i buffer intermedi cambiano a seconda dell’API e del dispositivo.

Anche il dispositivo può avere elaborazioni e buffer propri, quindi la latenza complessiva non è determinata dal solo buffer dell’applicazione. Questa spiegazione presuppone il percorso della modalità condivisa e non significa che con ogni API si attraversino le stesse elaborazioni. Low Latency Audio

Rifornire con 10 millisecondi residui

Supponiamo che nel buffer restino in questo momento 10 millisecondi di dati non ancora riprodotti. Se il rifornimento successivo arriva dopo 8 millisecondi, la riproduzione prosegue senza stacchi finché resta qualcosa; ma se non si riesce a rifornire prima di 12 millisecondi, in questo esempio semplificato i dati si esauriscono al decimo millisecondo.

flowchart TB
    accTitle: Con gli stessi 10 millisecondi residui, l'esito cambia con l'istante del rifornimento
    accDescr: Con l'ipotesi illustrativa di 10 millisecondi di dati residui, mostra che un rifornimento dopo 8 millisecondi arriva in tempo, mentre uno dopo 12 millisecondi arriva quando i dati sono già esauriti.
    A["Restano 10 millisecondi"] --> B{"Prossimo rifornimento"}
    B -->|"Dopo 8 millisecondi"| C["Nessuno stacco"]
    B -->|"Dopo 12 millisecondi"| D["Esauriti a 10 millisecondi"]

Figura 3: Esempio con tempi semplificati. Conta non solo se il rifornimento è avvenuto, ma anche quando.

Uso della CPU e ritardi di rifornimento

L’uso della CPU indica quanto la CPU è stata occupata in un certo intervallo di tempo. È una misura diversa dal sapere se l’elaborazione audio è riuscita a essere eseguita nell’istante in cui serviva. Anche se per gran parte del secondo la CPU ha margine, basta un solo intervallo di 12 millisecondi senza rifornimento perché quell’unico ritardo possa interrompere l’audio. Il margine di capacità di elaborazione che resta dopo non permette di recuperare un istante di riproduzione ormai passato. CPU Analysis

flowchart TB
    accTitle: Margine medio e un singolo ritardo di rifornimento
    accDescr: Anche se per gran parte del secondo la CPU ha margine, un solo intervallo di 12 millisecondi senza rifornimento può bastare a interrompere l'audio.
    A["CPU libera per gran parte del secondo"] --> B["Una volta 12 millisecondi senza rifornimento"]
    B --> C["Quell'unica volta interrompe l'audio"]

Figura 4: Anche con un margine medio, un istante di riproduzione ormai passato non si recupera.

A erodere la scadenza non è solo il tempo di calcolo. Contano anche l’attesa prima che l’elaborazione cominci e l’attesa che arrivino i dati necessari. Per questo anche la domanda dell’indagine non si ferma più a «quale percentuale segnava la CPU?», ma diventa «nell’istante in cui l’audio si è interrotto, che cosa stava aspettando l’audio successivo?».

Attese su dati e lock

Supponiamo che l’elaborazione che prepara i dati audio stia aspettando che la lettura di un file sia completata. Lo stesso vale se aspetta un lock detenuto da un’altra elaborazione all’interno dell’applicazione. L’elaborazione in attesa, di per sé, usa poca CPU, ma sul lato del dispositivo la riproduzione continua e l’audio residuo diminuisce. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: La riproduzione avanza anche durante le attese che non usano la CPU
    accDescr: Mentre l'elaborazione audio attende dati o lock non usa la CPU, ma la riproduzione avanza e il residuo diminuisce; se il rifornimento arriva in ritardo, il buffer può esaurirsi.
    A["L'elaborazione audio attende i dati"] --> B["Quell'elaborazione non usa CPU"]
    B --> C["Intanto la riproduzione avanza"]
    C --> D["Rifornimento in ritardo: scorte esaurite"]

Figura 5: Non usare la CPU e aver terminato il lavoro necessario sono due cose diverse.

DPC, ISR e thread audio

Una ISR è l’elaborazione che risponde a un interrupt proveniente da un dispositivo. Un DPC è il meccanismo che rimanda a più tardi il lavoro rimanente per mantenere breve la gestione dell’interrupt. I DPC normali vengono eseguiti prima dei thread normali sulla stessa CPU logica e, mentre è in esecuzione un DPC o una ISR normale, quella CPU logica non può eseguire thread normali. Introduction to DPCs, CPU Analysis

Anche se la CPU nel suo complesso ha margine, se questi si prolungano o si ripetono spesso sulla CPU di cui l’elaborazione audio ha bisogno, la fornitura può arrivare in ritardo. Nella documentazione di Microsoft sull’analisi delle prestazioni audio e video, anche DPC/ISR lunghi dovuti a driver di rete, di archiviazione, grafici e simili sono indicati tra le possibili cause delle interruzioni audio. Non è detto che basti esaminare il solo dispositivo che emette il suono. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Quando la risposta ai dispositivi ritarda l'esecuzione audio
    accDescr: Se DPC o ISR normali si prolungano sulla CPU necessaria all'elaborazione audio, l'esecuzione del thread viene ritardata e la scadenza di rifornimento può risentirne.
    A["DPC e ISR sulla stessa CPU"] -->|"Se si prolungano"| B["L'esecuzione audio deve attendere"]
    B --> C["Il rifornimento successivo tarda"]
    C --> D["Esaurito il residuo, l'audio salta"]

Figura 6: Anche l’elaborazione legata a dispositivi diversi da quello che emette il suono può influire indirettamente sul rifornimento audio.

Non si può tracciare una soglia comune del tipo «se i DPC restano sotto tanti microsecondi, nessun PC avrà interruzioni». I valori di avviso della documentazione di valutazione delle prestazioni valgono per quelle condizioni di valutazione e non vanno usati come criterio di sicurezza separandoli dalla scadenza effettiva di rifornimento e dal margine del buffer. Results for the Streaming Media Performance Assessment

Quantità di buffer e latenza di riproduzione

A parità di condizioni, accumulare più audio in anticipo rende più facile assorbire i ritardi di rifornimento temporanei, ma l’audio appena generato deve attendere dietro quello già accumulato. Un’attesa accettabile quando si ascolta soltanto musica diventa uno scarto fastidioso tra azione e suono quando si suona una tastiera o quando si ascolta la propria voce del microfono dopo averla elaborata. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Margine del buffer e ritardo di risposta
    accDescr: Accumulare più audio in anticipo aiuta ad assorbire i ritardi di rifornimento temporanei, ma aumenta anche l'attesa prima che il nuovo audio venga riprodotto.
    A["Accumulare più audio in anticipo"] --> B["Ritardi più facili da assorbire"]
    B -->|"In cambio"| C["Il nuovo audio attende in coda"]
    C --> D["Più ritardo tra azione e suono"]

Figura 7: Aumentare il buffer è una regolazione che crea margine a scapito della rapidità di risposta.

Non vale né «più è piccolo, più è performante» né «più è grande, meglio è». Si cerca un margine sufficiente a evitare interruzioni, conservando la rapidità di risposta necessaria.

Aumentare il buffer è una regolazione che crea margine contro ritardi di fornitura temporanei. Se è la fornitura media in sé a non tenere il passo con il consumo, ingrandire un buffer finito allunga soltanto il tempo che passa prima che si esaurisca, e non risolve nemmeno la disconnessione del dispositivo. Né si raccomanda la modalità esclusiva come soluzione di tutto. Exclusive-Mode Streams

Audio a 48 kHz e 480 frame

Un frame PCM è l’unità che raggruppa i campioni di tutti i canali da riprodurre nello stesso istante. Il fatto che l’audio sia stereo non significa che il tempo si calcoli raddoppiando il numero di frame. La durata dell’audio rappresentata da un numero di frame si ottiene con «numero di frame ÷ frequenza di campionamento»: a 48 kHz, 480 frame corrispondono a 480 ÷ 48000 secondi, cioè 10 millisecondi. Se a 48 kHz si aumenta il numero di frame, si allunga anche il tempo di audio che si può accumulare. Rendering a Stream

Questo tempo non coincide con la latenza totale tra la pressione di un tasto e il momento in cui si sente il suono. Ci sono infatti anche i tempi dell’applicazione, del driver, del dispositivo e di altri buffer ed elaborazioni. Anche i valori impostati in una DAW vanno letti verificando l’unità e il buffer a cui si riferiscono. Low Latency Audio

flowchart TB
    accTitle: Il tempo ricavato dal numero di frame e la latenza totale
    accDescr: I 10 millisecondi ottenuti dividendo 480 frame per 48000 sono il tempo rappresentato dal buffer; aggiungendo le elaborazioni di applicazione, driver, dispositivo e così via si ottiene la latenza totale dal tasto al suono.
    A["480 ÷ 48000"] --> B["I 10 millisecondi del buffer"]
    B -->|"Si aggiungono altre elaborazioni"| C["Latenza totale dal tasto al suono"]

Figura 8: Il tempo ricavato dal numero di frame è una parte della latenza totale.

Confrontare le condizioni di comparsa

Per prima cosa si restringe la combinazione in cui il problema si presenta, e solo se serve si passa a una registrazione dettagliata. Quella che segue è una procedura per verificare la causa, non un elenco di rimedi in cui applicare tutte le modifiche alle impostazioni in una volta.

Salvate il vostro lavoro, concludete eventuali riunioni o registrazioni reali e fate le prove a un volume che non affatichi l’udito. Annotate l’uscita originale, i miglioramenti audio, i valori del buffer e così via, in modo da poter tornare indietro. Saltate le voci per cui non è disponibile un’impostazione e non modificate il Registro di sistema o altro per far comparire opzioni di impostazione.

1. Stabilite una stessa breve sorgente audio e un tempo di osservazione, e verificate che il problema si presenti nelle condizioni originali.

   Registrate la versione di Windows, il nome e la versione dell’applicazione, il dispositivo di uscita, il tipo di connessione e la versione del driver. Annotate anche l’ora, l’operazione e il numero delle interruzioni. Se nelle condizioni originali il problema non si presenta, non concludete che sia migliorato: tornate a verificare le condizioni in cui si presenta.

2. Scegliete un confronto dalla tabella seguente e riproducete l’audio cambiando solo quella condizione.

   Condizione da confrontare	Che cosa verificare
   Sorgente salvata in locale e riproduzione via rete	Se si verifica solo via rete. Anche a parità di contenuto, se formato o percorso di elaborazione sono diversi, annotate anche questo.
   Stessa sorgente riprodotta con un’altra applicazione	Se si concentra in una determinata applicazione.
   Uscita Bluetooth o simili e uscita integrata o cablata	Se si concentra in un determinato percorso di uscita.
   Miglioramenti audio attivati e disattivati	Se cambia in combinazione con l’elaborazione degli effetti.
   Buffer attuale della DAW o simili e valore di un passo più grande	Se cambia aumentando il margine accumulato in anticipo. Se anche il ritardo tra azione e suono resta accettabile.

3. Se confrontate i miglioramenti audio, disattivate temporaneamente l’impostazione sull’uscita interessata.

   In Windows aprite «Impostazioni» → «Sistema» → «Audio», selezionate l’uscita interessata e, dove disponibile, disattivate «Miglioramenti audio». Se le schermate o la presenza delle voci sono diverse, consultate le indicazioni per quella versione o quel dispositivo. Fix distorted or crackling audio in Windows

4. Riportate l’impostazione modificata al valore originale e riprovate con la stessa sorgente e lo stesso tempo di osservazione.

   Mettete a confronto i risultati di «condizione originale», «una condizione modificata» e «condizione ripristinata». Riportate allo stato originale una modifica senza effetto prima di passare a un altro confronto. Se continuate a cambiare combinazioni di impostazioni, non si capisce più che cosa abbia avuto effetto.

5. Se provate a cambiare il driver, fatelo dopo aver verificato la distribuzione ufficiale e il metodo di ripristino.

   Usate Windows Update o la distribuzione ufficiale del produttore del dispositivo e registrate versione e impostazioni prima e dopo la modifica. Verificate in anticipo di poter tornare indietro e, sui PC gestiti, consultatevi con l’amministratore. Non considerate risolto il problema solo perché subito dopo l’aggiornamento una riproduzione è andata bene: verificate nelle stesse condizioni di comparsa. Fix distorted or crackling audio in Windows

Il risultato da ottenere è un resoconto che associa sintomo e condizioni, del tipo «si presenta con questa applicazione quando si usa questa uscita». Anche quando trovate un’impostazione che migliora la situazione, tenetela distinta dall’individuazione della causa.

flowchart TB
    accTitle: Confronto cambiando una condizione e ripristinandola
    accDescr: Si verifica che il problema si presenti con la stessa sorgente, si cambia una condizione come l'applicazione o l'uscita e si registra anche il risultato dopo il ripristino.
    A["Riprodurre con la combinazione originale"] --> B["Riprodurre cambiando una condizione"]
    B --> C["Riprodurre dopo il ripristino"]
    C --> D["Annotare condizioni e ora delle interruzioni"]

Figura 9: Più che un singolo miglioramento, si verifica che condizioni e sintomo corrispondano in modo ripetuto.

Riproducibilità prima e dopo la modifica

«Sintomo attenuato», «condizioni ristrette» e «causa radice individuata» sono traguardi diversi. Registrate la conclusione in base a ciò che avete effettivamente potuto osservare.

flowchart TB
    accTitle: Tre risultati che indicano una correlazione con la condizione
    accDescr: Se il problema si presenta nelle condizioni originali, migliora cambiando una condizione e si ripresenta dopo il ripristino, è un indizio di correlazione con quella condizione, ma va tenuto distinto dall'individuazione della causa.
    A["Si presenta nelle condizioni originali"] --> B["Migliora cambiandone una"]
    B --> C["Si ripresenta col ripristino"]
    C --> D["Indizio di correlazione con la condizione"]

Figura 10: Anche con tutti e tre i risultati, si arriva al massimo a un indizio di correlazione.

Un uso della CPU basso non è la prova che le scadenze audio siano state rispettate. Allo stesso tempo, il solo fatto che ci sia stata un’interruzione non permette di dire che la causa radice fosse un ritardo di rifornimento. Confrontate sorgente, elaborazione dell’applicazione, effetti, percorso di uscita e così via, e giudicate entro i limiti di ciò che avete osservato. Fix distorted or crackling audio in Windows

Quando adottate una soluzione temporanea, annotate l’impostazione originale, la modifica apportata, il tempo di osservazione, se il problema si è ripresentato e la latenza accettabile. Se la causa radice non è stata individuata, annotate anche questo.

Registrare le interruzioni con WPR

Questo passo si esegue quando il solo confronto delle condizioni non basta a restringere il campo, oppure quando si vuole esaminare l’elaborazione lato driver. WPR è lo strumento per registrare, WPA quello per analizzare la linea temporale salvata. Preparate il Windows Performance Toolkit, i permessi necessari per registrare e una destinazione in cui salvare l’ETL. Se dovete installare lo strumento e registrare su un PC gestito, rivolgetevi all’amministratore. Verificate i nomi visualizzati e i profili disponibili nella versione installata. Windows Performance Recorder

Un ETL può contenere nomi di processi, percorsi di file e altro. Prima di registrare verificate le regole aziendali e con chi lo condividerete, e non allegatelo così com’è in luoghi pubblici. Se è in corso un’altra sessione di registrazione, non interrompetela di vostra iniziativa: chiedete alla persona responsabile. WPR How-to Topics

1. Aprite «More Options» in WPR e scegliete un profilo di registrazione adatto allo scopo.

   Tra i profili predefiniti ci sono «Audio glitches» e «CPU usage». Scegliete impostazioni che permettano di esaminare le discontinuità dell’audio e l’attività della CPU. Verificate profili disponibili, nomi visualizzati e dati raccolti nella versione installata, e non impostate una registrazione prolungata di tutti i tipi. Built-in Recording Profiles

2. Avviate la registrazione prima di ricreare l’interruzione.

   Se compare una richiesta di conferma per interrompere una registrazione esistente, non proseguite: annullate l’avvio e chiedete alla persona responsabile. Mantenete le stesse condizioni del caso senza registrazione, tenendo presente che il carico della registrazione stessa potrebbe modificare il sintomo. WPR How-to Topics

3. Riproducete l’audio nelle condizioni individuate con il confronto e annotate l’ora delle interruzioni e le operazioni eseguite.

   Includete anche un breve tratto senza problemi prima e dopo il sintomo. Se in una registrazione il problema non si è presentato, indicatelo chiaramente e non trattatela come una registrazione che ha catturato la causa.

4. Dopo aver ricreato il problema, terminate la registrazione con «Save» e salvate il file ETL.

   Con «Cancel» non viene salvato nulla. Annotate la destinazione di salvataggio, le condizioni di comparsa, se la registrazione è stata effettuata e se è comparso un avviso di eventi persi. In una registrazione con eventi persi, non giudicate normali gli intervalli che non si vedono. WPR How-to Topics

Quando avete il file ETL e le note su ora, operazioni e condizioni delle interruzioni, siete pronti per il confronto in WPA. Il solo fatto di aver salvato la registrazione non garantisce che gli eventi necessari siano stati acquisiti. Il contenuto si verifica nella sezione seguente, «Esecuzione e attese attorno all’interruzione».

flowchart TB
    accTitle: Acquisire una breve registrazione che includa l'interruzione
    accDescr: Si avvia la registrazione con WPR, si ricrea il sintomo annotandone l'ora, si arresta e si salva, e si esamina la registrazione salvata in WPA.
    A["Avviare la registrazione in WPR"] --> B["Ricreare l'interruzione nelle stesse condizioni"]
    B --> C["Annotare ora e operazioni, salvare"]
    C --> D["Ingrandire l'intervallo in WPA"]

Figura 11: L’uso della CPU osservato quando il sintomo è già finito non basta: serve una registrazione dell’intervallo in cui il sintomo si è verificato.

Esecuzione e attese attorno all’interruzione

Preparate l’ETL salvato e le note sull’ora in cui il problema si è presentato. Quanto segue è un punto di partenza per l’indagine in WPA. Se serve un’analisi dettagliata con stack e simboli, affidatela all’amministratore o agli sviluppatori, facendo attenzione a come gestite la registrazione.

1. Aprite l’ETL in WPA e, in base agli eventi audio acquisiti e all’ora in cui il problema si è presentato, ingrandite l’intervallo prima e dopo l’interruzione.

   Tenete anche un intervallo senza sintomi per il confronto. Non guardate solo la classifica dei valori massimi: confrontate allineando lo stesso intervallo di tempo.

2. Nello stesso intervallo esaminate «DPC/ISR» e «CPU Usage (Precise)».

   Se mancano i dati necessari, verificate che il profilo li raccolga e tornate alla registrazione con WPR. L’assenza di dati registrati e l’assenza di problemi sono cose diverse. CPU Analysis, Built-in Recording Profiles

3. Distinguete se i thread legati all’audio erano pronti per l’esecuzione ma in coda, oppure se stavano aspettando dati o altro.

   Nel primo caso, verificate se sulle CPU logiche interessate DPC/ISR o simili restavano in esecuzione a lungo. Nel secondo, seguite con gli eventi e gli stack acquisiti che cosa ha sbloccato l’attesa. Poiché anche un thread in esecuzione può essere interrotto da un interrupt, non limitatevi al tempo in stato Ready: sovrapponete anche gli intervalli di DPC/ISR. CPU Analysis

4. Registrate insieme la corrispondenza temporale con l’interruzione, le CPU coinvolte e i risultati ottenuti cambiando le condizioni.

   Non stabilite che un determinato dispositivo o driver sia la causa basandovi solo sul nome del modulo di un DPC/ISR lungo. Potreste star guardando un valore alto in un altro momento, oppure una parte comune attraversata da più dispositivi.

flowchart TB
    accTitle: Esaminare il tipo di attesa nell'intervallo dell'interruzione
    accDescr: Si ingrandisce l'intervallo attorno all'interruzione e si osserva lo stato del thread audio. Se era pronto ma in coda, lo si confronta con DPC e ISR sulla stessa CPU; se attendeva dati o altro, si segue l'elaborazione che ha sbloccato l'attesa.
    A["Ingrandire attorno all'interruzione"] --> B{"Stato del thread"}
    B -->|"In coda"| C["DPC e ISR"]
    B -->|"Attesa di dati"| D["Ciò che ha sbloccato l'attesa"]

Figura 12: Non limitatevi a raccogliere i valori massimi: leggeteli sovrapposti all’intervallo in cui serviva l’elaborazione audio.

Se non riuscite a individuare la causa, passate l’indagine ad altri indicandola come non conclusa. Allegate le versioni di sistema operativo, applicazione, dispositivo e driver, la procedura per ricreare il problema, i risultati prima e dopo le modifiche, l’ora in cui si è verificato, il profilo di raccolta e se ci sono stati avvisi di eventi persi. Condividete l’ETL, secondo le regole aziendali, solo con chi si occupa dell’indagine.

Lettura anticipata nelle applicazioni audio

Se sviluppate voi stessi un’applicazione audio, progettatela in modo che l’elaborazione che riempie il buffer successivo rispetti ogni volta la scadenza. WASAPI offre un modo per ricevere tramite un evento il momento in cui il buffer può essere elaborato. Exclusive-Mode Streams

MMCSS è un meccanismo che assegna risorse di CPU ai thread di elaborazione multimediale soggetti a vincoli di tempo. Non ha funzioni per preparare in anticipo i dati dal disco o per eliminare le attese sui lock. Anche quando sfruttate l’assegnazione di MMCSS, serve comunque, separatamente, una progettazione che si occupi della preparazione dei dati e riduca le attese. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Ciò di cui si occupa MMCSS
    accDescr: MMCSS assegna risorse di CPU ai thread di elaborazioni con vincoli di tempo, ma la preparazione dei dati e la riduzione delle attese sui lock si ottengono con una progettazione separata.
    M["MMCSS: assegna risorse di CPU"] -.->|"Serve a parte"| D["Preparare i dati e ridurre le attese"]

Figura 13: Assegnare risorse di CPU e progettare perché i dati arrivino in tempo sono compiti diversi.

Il principio di progettazione è separare l’elaborazione che legge da file o dalla rete da quella che consegna l’audio. La preparazione dalla durata difficile da prevedere va fatta in anticipo, e per il passaggio dei dati si usano buffer allocati in precedenza. Sul lato audio, la struttura deve evitare di dover attendere risposte dell’interfaccia utente, lock lunghi o scritture sincrone dei log.

flowchart TB
    accTitle: Separare la preparazione dai tempi imprevedibili dalla fornitura audio
    accDescr: Una progettazione in cui la lettura e simili avvengono in un'elaborazione anticipata e i dati pronti passano all'elaborazione audio tramite un buffer, riducendo le lunghe attese a ridosso della scadenza.
    A["Preparare i dati in anticipo"] --> B["Area di scambio preallocata"]
    B --> C["L'elaborazione audio passa il necessario"]
    C --> D["Fornire all'uscita audio"]

Figura 14: Il lavoro che richiede tempo viene tolto dal momento che precede la consegna dell’audio.

Se il lato di preparazione si blocca a lungo, le scorte si esauriscono anche con questa separazione. Oltre al tempo medio di elaborazione, registrate, con un metodo che non disturbi l’elaborazione audio, anche le occasioni in cui si sono verificate elaborazioni o attese lunghe e il numero di volte in cui non è stato possibile fornire i dati. Verificate tramite l’API o il driver la quantità di buffer e il periodo effettivamente scelti, senza presumere che il valore richiesto sia stato adottato così com’è. Rendering a Stream, Low Latency Audio

Sia gli esempi numerici sia gli esempi di progettazione hanno scopo illustrativo: non sono valori di impostazione consigliati per un dispositivo specifico, né una garanzia che l’audio non si interrompa in qualsiasi ambiente.

Gli effetti della priorità in tempo reale

Non consigliamo in modo generalizzato che chi usa il PC porti l’intero lettore alla priorità «Tempo reale». C’è il rischio di ostacolare altre elaborazioni importanti, e alzare la priorità di un thread normale non elimina le attese dovute a DPC/ISR né quelle su dati e lock. Nello sviluppo si usano meccanismi come MMCSS e una progettazione che non introduca lunghe attese nella fornitura audio. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Le attese che restano anche con la priorità in tempo reale
    accDescr: Anche portando il lettore alla priorità in tempo reale, un thread normale non può scavalcare DPC e ISR sulla stessa CPU, le attese su dati e lock restano e c'è anche il rischio di ostacolare altre elaborazioni importanti.
    A["Lettore a priorità in tempo reale"] --> B["DPC e ISR non si scavalcano"]
    B --> C["Restano le attese su dati e lock"]
    C --> D["Rischio di ostacolare altre elaborazioni"]

Figura 15: Anche alzando la priorità, le attese che ritardano il rifornimento audio restano.

Articoli correlati

• L’impostazione «Pianificazione processore» di Windows e i servizi in background
• Circoscrivere in sicurezza un disco Windows al 100%
• Perché RDP è lento su una connessione veloce?

Riferimenti

• Microsoft Learn, Rendering a Stream. Fornitura al buffer di riproduzione, quantità residua, dimensione effettiva del buffer e definizione di frame PCM.
• Microsoft Learn, Exclusive-Mode Streams. Istante di fornitura del buffer e glitch audio, compromesso con la latenza, fornitura guidata da eventi. Non è una raccomandazione generalizzata della modalità esclusiva in sé.
• Microsoft Learn, Low Latency Audio. Il percorso audio di Windows; buffer, dispositivi, elaborazione degli effetti e latenza; i compromessi della bassa latenza.
• Microsoft Learn, CPU Analysis. CPU logiche, stati Ready/Waiting dei thread, relazione tra DPC/ISR ed esecuzione dei thread, analisi della CPU in WPA.
• Microsoft Learn, Introduction to DPCs. Il meccanismo che mantiene breve la gestione degli interrupt e rimanda a un DPC il lavoro rimanente.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR lunghi o frequenti, fornitura di dati insufficiente e glitch audio. I valori di avviso della valutazione non vengono generalizzati come criterio di sicurezza per tutti i dispositivi.
• Microsoft Support, Fix distorted or crackling audio in Windows. Verifica di miglioramenti audio, formato, driver e altro.
• Microsoft Learn, Windows Performance Recorder. Registrazione ETW e analisi con WPA, uso del Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options di WPR e profili predefiniti come Audio glitches e CPU usage.
• Microsoft Learn, WPR How-to Topics. Avvio della registrazione e salvataggio con Save, conflitti con sessioni esistenti, attenzione ai dati personali e agli eventi persi.
• Microsoft Learn, Multimedia Class Scheduler Service. Assegnazione di risorse di CPU all’elaborazione multimediale soggetta a vincoli di tempo.
• Microsoft Learn, Scheduling Priorities. Priorità di processi e thread e avvertenze sulla priorità in tempo reale.

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste sono pagine di argomenti vicini a questo tema. A partire dall'articolo, potete passare ai servizi correlati e ad altri articoli.

Servizi collegati all’argomento

Questo articolo si collega alle pagine dei servizi seguenti. Partite da un ingresso vicino alla vostra situazione.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Perché l'audio si interrompe quando l'uso della CPU è intorno al 10%?

L'audio ha una scadenza: i dati successivi vanno riforniti prima che si esauriscano quelli in riproduzione. Anche se l'uso complessivo della CPU è basso, il rifornimento può non arrivare in tempo se in quell'istante l'elaborazione audio non riesce a essere eseguita o sta aspettando i dati che le servono. Non tutte le interruzioni hanno questa causa, quindi servono anche confronti cambiando dispositivo di uscita o applicazione.

Un buffer audio più grande elimina le interruzioni?

Se il rifornimento è in ritardo solo temporaneamente, un buffer più grande può assorbire il ritardo. Aumenta però anche l'attesa prima che l'audio accumulato venga riprodotto. Non è un'impostazione che risolve anche una carenza continua di capacità di elaborazione o la disconnessione del dispositivo. Nelle applicazioni e nei driver che permettono di modificarlo, annotate il valore originale e confrontate un passo alla volta.

A 48 kHz, quanti millisecondi di audio corrispondono a 480 frame?

480 ÷ 48000 secondi, quindi 10 millisecondi. Un frame PCM è l'unità che raggruppa i campioni di tutti i canali relativi allo stesso istante. Questo valore è la durata dell'audio rappresentata da quel numero di frame, non la latenza totale che include dispositivi e applicazioni.

Il colpevole delle interruzioni è un driver con tempi di esecuzione di DPC o ISR lunghi?

Può essere un candidato, ma la sola classifica dei tempi di esecuzione non basta a stabilirlo. Confrontate l'intervallo in cui si è verificata l'interruzione con le attese del thread audio e con l'esecuzione di DPC/ISR sulla stessa CPU. Non concludete dal solo nome del modulo che un determinato dispositivo o driver sia difettoso, e verificate anche i risultati ottenuti cambiando le condizioni in cui il problema si presenta.

Impostare il lettore sulla priorità in tempo reale migliora la situazione?

Non lo consigliamo in modo generalizzato. Alzare la priorità di un thread normale non gli permette di scavalcare i normali DPC e ISR sulla stessa CPU, né elimina le attese su dati o lock. Chi sviluppa usa meccanismi come MMCSS e una progettazione che non introduce attese, mentre chi usa il PC confronta prima le condizioni in cui il problema si presenta e il percorso di uscita.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Si occupa soprattutto di sviluppo di software Windows, consulenza tecnica e indagine sui malfunzionamenti, con punti di forza nei progetti in cui restano risorse esistenti e nelle indagini su guasti dalla causa difficile da individuare.