Perché l'audio si interrompe se l'uso della CPU è basso? — Ragionare in termini di buffer e scadenze

State ascoltando musica e ogni tanto si interrompe con uno scoppiettio. Aprite Gestione attività e l’uso della CPU si aggira sul 10%. Il video continua a essere riprodotto e il mouse si muove normalmente.

Viene voglia di chiedere: «con tutto questo margine, riprodurre audio è davvero troppo?»

Ma ciò di cui l’audio ha bisogno non è soltanto la capacità di sbrigare molto lavoro in fretta. Gli serve anche che il tratto di suono successivo sia pronto prima che quello in riproduzione si esaurisca. Questo articolo segue quel rifornimento tardivo, il meccanismo dietro una tipica interruzione.¹

Partiamo dalla scena della riproduzione di musica su un PC. Le sezioni da 1 a 4 concludono la trattazione del meccanismo, e dalla sezione 5 in poi si raccolgono i metodi di analisi. Si presuppone ovunque l’uscita audio su Windows 11, e i numeri sono ipotesi usate per la spiegazione.

1. L’audio viene riprodotto mentre un po’ di ciò che segue è tenuto di riserva

Un file musicale conservato sul PC non fa suonare gli altoparlanti per il solo fatto di stare lì. L’applicazione di riproduzione prepara i dati audio e li consegna, attraverso Windows e il driver, al dispositivo che produce il suono. Nella consueta modalità condivisa, il motore audio di Windows miscela lungo il percorso più flussi e applica effetti.²

Se l’audio venisse consegnato un pezzo alla volta esattamente quando serve, il minimo ritardo di elaborazione si ripercuoterebbe direttamente sulla riproduzione. Per questo un po’ di ciò che verrà riprodotto in seguito viene tenuto di riserva in anticipo. Quel luogo di custodia temporanea è il buffer. Mentre la riproduzione procede sul lato dispositivo, l’applicazione e l’elaborazione audio lo riforniscono con i dati successivi.³

flowchart TB
    accTitle: Mettere un po' di suono nel buffer e poi riprodurlo
    accDescr: Il flusso che rifornisce il buffer con i dati audio preparati e prepara i dati successivi mentre la riproduzione procede sul lato dispositivo.
    A["Preparare i dati audio successivi"] --> B["Rifornire il buffer"]
    B --> C["Riprodurre l'audio nel buffer"]
    C -.->|"Prima che il resto si esaurisca"| A

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

Poniamo che il buffer contenga al momento 10 millisecondi di audio. Se il rifornimento successivo arriva fra 8 millisecondi, si aggancia mentre ne resta ancora. Ma se non arriva nulla fino a 12 millisecondi, la scorta si esaurisce al traguardo dei 10 millisecondi.

flowchart TB
    accTitle: Gli stessi 10 millisecondi rimasti, risultato diverso a seconda di quando arriva il rifornimento
    accDescr: Come ipotesi usata per la spiegazione, si mostra che con 10 millisecondi di dati di riproduzione rimasti un rifornimento dopo 8 millisecondi arriva in tempo, mentre uno dopo 12 millisecondi arriva dopo l'esaurimento.
    A["Ora restano 10 millisecondi"] --> B["Rifornimento 8 ms dopo"]
    B --> C["Si aggancia mentre ne resta"]
    A --> D["Rifornimento 12 ms dopo"]
    D --> E["Scorta esaurita a 10 ms"]

Figura 2: Un esempio semplificato in termini di tempo. Ciò che conta non è solo se il rifornimento sia avvenuto, ma quando.

Restare a secco perché la fornitura dei dati audio necessari non arriva in tempo è un underrun. Porta a interruzioni, clic e artefatti simili. Anche se i dati si presentano in ritardo, un vuoto già udito non può essere colmato a posteriori.¹

La riproduzione audio è un lavoro per cui «alla fine è stato calcolato» non basta; ciò che serve è «era pronto nel momento in cui doveva suonare».

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

2. Perché il rifornimento è in ritardo anche se la CPU è inattiva

Sentendo tutto questo, la reazione naturale è: «se la CPU è inattiva, perché non rifornire prima?»

Ma il numero dell’uso della CPU non è un conteggio delle scadenze audio rispettate. Quanto sia stata occupata l’intera CPU in un certo intervallo e se il breve lavoro che rifornisce l’audio sia riuscito a essere eseguito nel momento necessario sono due cose diverse. Un carico complessivo basso non garantisce che il lavoro audio ottenga il proprio turno subito ogni volta.⁴

Nei termini dell’esempio precedente, anche se c’è margine per gran parte di un secondo, un solo tratto in cui il rifornimento non può avvenire per 12 millisecondi esaurisce i 10 millisecondi di audio rimasti. Il margine presente più avanti nel secondo non salva quell’unico arrivo tardivo.

Non un calcolo lento, ma l’attesa di un’occasione per essere eseguito

Supponiamo che il codice che prepara i dati audio stia aspettando la fine di una lettura da file. Oppure che attenda un lock detenuto da un altro lavoro all’interno dell’applicazione. Mentre attende, quel codice consuma poca CPU. L’audio già in riproduzione continua comunque a scorrere. Una fornitura di dati tardiva e un thread in attesa si verificano indipendentemente dall’esaurimento della CPU.⁵⁴

flowchart TB
    accTitle: La riproduzione avanza anche durante un'attesa che non consuma CPU
    accDescr: La riproduzione avanza mentre l'elaborazione audio attende dati o un lock, così il buffer può svuotarsi con l'uso della CPU ancora basso.
    A["L'elaborazione audio attende dati"] --> B["Quel lavoro non consuma CPU"]
    A --> C["La riproduzione continua e il resto si riduce"]
    C --> D["Un rifornimento tardivo significa restare a secco"]

Figura 3: «Non usare la CPU» non è la stessa cosa di «il lavoro necessario è fatto».

Anche dispositivi apparentemente estranei all’audio possono trattenerlo

C’è un secondo caso, in cui il turno non arriva sul lato Windows.

Quando giunge una notifica da un dispositivo di rete o simile, Windows esegue il codice che gestisce l’interrupt. La breve prima parte di quel lavoro è la ISR, e il meccanismo che rimanda il resto del lavoro è il DPC. Mentre un DPC o una ISR ordinaria è in esecuzione, quella CPU logica non può eseguire thread ordinari. Anche l’elaborazione audio vi è soggetta.⁶⁴

Quando tale lavoro dura a lungo o si presenta spesso sulla CPU su cui l’audio deve essere eseguito, l’occasione di rifornire l’audio viene spostata più avanti. Anche il materiale Microsoft sull’analisi delle prestazioni per audio e video spiega che DPC e ISR lunghi provenienti da driver di rete, archiviazione, grafica e altri possono causare artefatti audio.⁵

flowchart TB
    accTitle: Quando rispondere a un dispositivo ritarda l'esecuzione dell'audio
    accDescr: Quando un DPC o una ISR ordinaria dura a lungo sulla CPU di cui l'elaborazione audio ha bisogno, l'esecuzione del thread viene ritardata e la scadenza di rifornimento può risentirne.
    A["DPC o ISR sulla stessa CPU"] -->|"Quando dura a lungo"| B["L'esecuzione dell'audio viene trattenuta"]
    B --> C["Il rifornimento successivo è in ritardo"]
    C --> D["Un'interruzione quando il resto si esaurisce"]

Figura 4: Non solo il dispositivo che produce il suono; il lavoro destinato ad altri dispositivi può avere un effetto indiretto.

In altre parole, un’interruzione non è soltanto «la CPU è troppo lenta per terminare il calcolo». Il calcolo non riesce a partire, oppure i dati che gli servono non arrivano. Anche quell’attesa è tempo sottratto alla scadenza dell’audio.

3. Perché allora non tenere semplicemente molto audio di riserva?

Se il rifornimento è un po’ in ritardo, sembra sensato tenere scorta a sufficienza per assorbire quel ritardo. È esattamente il ragionamento che porta a ingrandire il buffer audio.

A parità di condizioni, tenere più audio in anticipo rende più facile superare brevi ritardi di rifornimento. Ma ora l’audio appena prodotto attende dietro a quello già tenuto di riserva.¹²

Se state solo ascoltando musica, attendere un attimo dopo aver premuto Riproduci forse non vi dà fastidio. Quando suonate una tastiera collegata al PC, o elaborate la vostra voce da un microfono e la ascoltate, quell’attesa diventa uno scarto fra il gesto e il suono.

flowchart TB
    accTitle: Margine del buffer e risposta più lenta
    accDescr: Tenere più audio in anticipo rende più facile assorbire i ritardi temporanei di rifornimento, mentre cresce anche l'attesa prima che il nuovo audio venga riprodotto.
    A["Tenere più audio in anticipo"] --> B["I ritardi di rifornimento si assorbono meglio"]
    A --> C["Il nuovo audio attende dietro"]
    C --> D["Più ritardo dal gesto al suono"]

Figura 5: Aumentare il buffer è una regolazione che compra margine al prezzo della reattività.

Anche le impostazioni di buffer 128, 256 e 512 che si trovano nei software di produzione musicale riguardano questo tempo. In PCM, l’unità che raggruppa i campioni di tutti i canali nello stesso istante si chiama frame. A 48 kHz, 480 frame sono 480 diviso 48000 secondi, cioè 10 millisecondi di audio. A parità di frequenza di campionamento, più frame ci sono, più lungo è il tratto di audio che contengono.³

Ciò che si è contato qui è la durata dell’audio che quel buffer rappresenta. Nella pratica c’è anche elaborazione nell’applicazione, nel driver e nel dispositivo, quindi tenetelo distinto dalla latenza complessiva fra la pressione di un tasto e l’ascolto della nota. Né tutte le applicazioni su Windows condividono un’unica impostazione comune di buffer; anche le dimensioni selezionabili variano con il dispositivo e il driver.²

Quindi più piccolo non significa prestazioni migliori, e nemmeno più grande è la risposta giusta. La regolazione consiste nel mantenere la reattività che vi serve prendendo abbastanza margine da evitare le interruzioni.

4. Ciò di cui l’audio ha bisogno è rispettare scadenze, non una velocità media

Torniamo alla domanda iniziale.

L’audio si interrompe con un uso basso della CPU perché avere margine nella capacità complessiva di elaborazione e consegnare in tempo il tratto di suono successivo sono due cose diverse.

L’audio viene riprodotto a partire da una piccola quantità tenuta di riserva. Quella scorta viene rifornita prima di esaurirsi. Un solo rifornimento tardivo può bastare a produrre un vuoto, e aumentare la scorta aggiunge margine ma allunga anche il tempo prima che il nuovo audio si senta.

Questo è il nocciolo del meccanismo. Cambia anche la domanda che ci si pone nell’analisi, da «a che percentuale era la CPU» a «nell’istante in cui l’audio si è interrotto, che cosa stava aspettando il tratto di suono successivo». Da qui in avanti viene la parte di analisi, per circoscrivere un sintomo reale.

5. Analisi: scoprite prima quale combinazione si interrompe

Uno scoppiettio che avete sentito non dimostra da solo l’underrun descritto finora. Il materiale di partenza stesso, l’elaborazione dell’applicazione, gli effetti audio, il dispositivo di uscita e altri problemi producono sintomi simili. Anche il materiale Microsoft sulla risoluzione dei problemi elenca i miglioramenti audio, il formato e i driver fra le cose da controllare.⁷

Non modificate le impostazioni in blocco all’inizio. Riproducete la stessa sorgente breve per circa la stessa durata e confrontate le differenze una alla volta. Fatelo al di fuori di una riunione o di una registrazione in corso, dopo aver salvato il vostro lavoro, e a un volume che non affatichi le orecchie.

In quest’ordine, la lamentela in una riga «l’audio si interrompe» può diventare abbastanza concreta da dire «si interrompe solo in questa applicazione, quando si usa questa uscita». Annullare ogni modifica e riprovare rende anche più facile capire se il sintomo semplicemente non si è presentato per caso.

flowchart TB
    accTitle: Confronto che cambia una condizione e poi la annulla
    accDescr: Confermare la riproduzione con la stessa sorgente, cambiare una condizione come l'applicazione o l'uscita e registrare anche il risultato dopo l'annullamento.
    A["Riprodurre con la combinazione originale"] --> B["Cambiare una condizione e riprodurre"]
    B --> C["Annullare e riprodurre"]
    C --> D["Registrare condizioni e orari delle interruzioni"]

Figura 6: Più che un singolo miglioramento, confermate che condizione e sintomo coincidano ripetutamente.

Notate che cambiare l’uscita cambia anche driver, buffer e altro. «Via cavo non si interrompe» è un indizio per indagare il percorso di uscita, ma da solo non dimostra che la trasmissione radio sia la causa. Allo stesso modo, un miglioramento ottenuto con un buffer più grande è un indizio che un margine di tempo aggiuntivo ha aiutato; non dimostra un difetto di un driver specifico.

Per confrontare i miglioramenti audio, selezionate in Windows l’uscita in questione in Impostazioni > Sistema > Audio e, dove disponibile, disattivate i miglioramenti audio e riprovate. Annotate l’impostazione originale e ripristinatela se non fa differenza. Procuratevi i driver da Windows Update o dalla distribuzione ufficiale del produttore del dispositivo, e registrate le versioni prima e dopo la modifica.⁷

6. Analisi: registrate l’istante dell’interruzione e ingranditelo

Quando il confronto delle condizioni non circoscrive nulla, o quando sospettate un’elaborazione sul lato driver, registrate ciò che accade in un breve intervallo. Windows Performance Recorder (WPR) esegue la registrazione, e Windows Performance Analyzer (WPA) è lo strumento per esaminare in dettaglio la cronologia registrata.⁸

Avviate la registrazione prima di riprodurre il problema

Su una macchina in cui è installato il Windows Performance Toolkit, aprite More Options nella finestra di WPR. Fra i profili integrati ci sono Audio glitches e CPU usage. Partendo dal primo, scegliete una registrazione che consenta di esaminare le discontinuità audio insieme all’attività della CPU. Verificate i profili disponibili e i loro nomi visualizzati nella versione che avete installato.⁹

Avviate la registrazione, poi riproducete audio nelle condizioni individuate in precedenza. Annotate gli orari delle interruzioni e ciò che stavate facendo e, dopo aver riprodotto il sintomo, terminate la registrazione con Save per scrivere il file ETL. Cancel non la salva. Includere un po’ di un tratto pulito vi dà un termine di paragone. Se vi viene chiesto di interrompere una registrazione esistente, annullate l’avvio e verificate con la persona responsabile, per non interrompere un’altra analisi.¹⁰

flowchart TB
    accTitle: Fare una breve registrazione che includa l'interruzione
    accDescr: Avviare una registrazione in WPR, riprodurre il sintomo e annotare l'orario, poi fermare e salvare la registrazione ed esaminarla in WPA.
    A["Avviare la registrazione in WPR"] --> B["Riprodurre l'interruzione nelle stesse condizioni"]
    B --> C["Annotare orario e azioni, poi salvare"]
    C --> D["Ingrandire l'intervallo circostante in WPA"]

Figura 7: Conservate l’intervallo in cui si è verificato il sintomo, non l’uso della CPU a cose fatte.

Un file ETL può contenere nomi di processi, percorsi di file e simili, quindi seguite le regole della vostra organizzazione e condividetelo solo con le persone che ne hanno bisogno. La registrazione può richiedere privilegi o strumenti aggiuntivi; su un PC aziendale rivolgetevi a un amministratore. Poiché il carico della registrazione stessa può modificare il sintomo, annotate se una registrazione era in corso. Preferite una registrazione breve adatta al vostro obiettivo a una lunga con tutti i provider attivati. In una registrazione che segnala eventi persi, non date per sani gli intervalli che non riuscite a vedere.¹⁰

Che cosa è accaduto nello stesso momento, anziché una classifica dei numeri grandi

In WPA ingrandite l’area intorno all’interruzione, servendovi degli eventi audio catturati e degli orari annotati. Nello stesso intervallo di tempo controllate DPC/ISR e CPU Usage (Precise), che mostra esecuzione e attese dei thread. Se quei dati mancano, verificate se il profilo cattura gli eventi necessari e registrate di nuovo. Un’assenza di registrazioni non equivale a un’assenza di problemi.⁴⁹

Il punto di partenza è capire se il thread legato all’audio fosse pronto per l’esecuzione ma in attesa del proprio turno, oppure non potesse essere eseguito perché attendeva dati o qualcosa di simile. Nel primo caso, cercate DPC, ISR e simili che si siano protratti su quella CPU. Nel secondo, ricostruite che cosa abbia sbloccato l’attesa, con le registrazioni e gli stack disponibili. Poiché anche un thread in esecuzione può essere interrotto, non restringete il campo al solo tempo Ready; sovrapponete gli intervalli in cui DPC e ISR sono stati eseguiti.⁴

flowchart TB
    accTitle: Esaminare come si è atteso durante l'intervallo dell'interruzione
    accDescr: Per il thread audio nell'intervallo considerato, separare l'attesa in stato pronto dall'attesa su dati o simili e confrontare le registrazioni corrispondenti.
    A["Lo stesso intervallo intorno all'interruzione"] --> B["Pronto per l'esecuzione ma in attesa del turno"]
    A --> C["In attesa di dati o simili"]
    B --> D["Confrontare il lavoro sulla stessa CPU"]
    C --> E["Ricostruire che cosa ha sbloccato l'attesa"]

Figura 8: Non isolate i soli valori massimi; leggeteli sovrapposti all’intervallo in cui l’elaborazione audio era necessaria.

Anche quando trovate un DPC o una ISR lunghi, non guardate il nome del modulo per decidere subito «il colpevole è questo driver». Potreste avere davanti un valore elevato di un altro momento, o un componente condiviso attraversato da più dispositivi. Combinate la corrispondenza temporale con l’interruzione, le CPU coinvolte e i risultati dei cambi di condizione, e chiedete al produttore del dispositivo di indagare se necessario.

Né si può tracciare una linea universale del tipo «un DPC sotto un certo numero di microsecondi non causa mai un’interruzione su nessun PC». Le soglie di avviso nella documentazione sono condizionate da quella valutazione. Non usatele come test di idoneità slegato dalla reale scadenza di rifornimento e dal margine del buffer.⁵

7. Per chi sviluppa: non introducete lunghe attese nel codice che consegna l’audio

Quando siete voi a costruire un’applicazione audio, il punto di partenza è lo stesso. Il codice che riempie il buffer successivo deve rispettare ogni scadenza.

WASAPI offre un modo per ricevere, sotto forma di evento, il momento in cui un buffer può essere elaborato. MMCSS, a sua volta, facilita l’assegnazione di tempo di CPU ai thread che svolgono lavoro multimediale con vincoli temporali. Nessuno dei due è però una magia che elimina le attese. MMCSS non vi prepara nemmeno in anticipo i dati audio dal disco.¹¹¹

La progettazione adatta consiste nel separare il codice che legge da file o dalla rete da quello che consegna l’audio. Svolgete in anticipo il lavoro il cui comportamento temporale è difficile da prevedere, e usate per la consegna un buffer preallocato. Sul lato audio, fate in modo che non occorra attendere una risposta dell’interfaccia, un lock lungo, una scrittura sincrona di log o simili. È una linea di progetto per disaccoppiare le attese sui dati dalla scadenza.

flowchart TB
    accTitle: Separare la preparazione difficile da prevedere dalla fornitura audio
    accDescr: Una progettazione che svolge in anticipo letture e lavori analoghi e passa i dati preparati all'elaborazione audio tramite un buffer, riducendo le lunghe attese appena prima della scadenza.
    A["Preparare i dati in lavoro svolto in anticipo"] --> B["Area di consegna preallocata"]
    B --> C["Consegnare all'elaborazione audio ciò che le serve"]
    C --> D["Alimentare la destinazione di uscita audio"]

Figura 9: Il punto non è eliminare il lavoro lento, ma spostarlo fuori dall’istante che precede la consegna dell’audio.

Anche con questa separazione, la scorta si esaurisce se il lato preparazione si blocca a lungo. Oltre al tempo medio di elaborazione, registrate le occasioni in cui elaborazione o attesa si sono protratte e il numero di fallimenti nella fornitura, in un modo che non disturbi l’elaborazione audio. Verificate la dimensione del buffer e il periodo effettivamente scelti tramite l’API o il driver, e non date per scontato che «il valore che ho indicato sia stato adottato tale e quale».³²

Evitate di consigliare agli utenti di impostare l’intero lettore su priorità in tempo reale. Rischia di ostacolare altro lavoro importante, e alzare la priorità di un thread ordinario non risolve DPC, ISR o attese sui dati.¹²⁴

8. Riepilogo: un uso basso della CPU non prova che la scadenza audio sia stata rispettata

Ci sono tre assi per ragionare sulle interruzioni: tenere audio di riserva, rifornirlo prima che si esaurisca, e un rifornimento tardivo significa un vuoto. Anche con un uso basso della CPU, un’attesa nel momento che conta può far arrivare il rifornimento in ritardo.

Iniziate confrontando applicazioni e uscite con la stessa sorgente e, se ciò non spiega ancora nulla, registrate l’intervallo dell’interruzione. Passare da «perché, se la CPU ha margine» a «che cosa stava aspettando in quell’istante» porta in vista la cosa successiva da esaminare.

Articoli correlati

• Impostazioni di scheduling del processore Windows e servizi in background
• Circoscrivere in sicurezza un disco Windows al 100%
• Perché RDP è lento su una connessione veloce?

Link di riferimento

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

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

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

L'audio ha una scadenza: i dati successivi devono essere riforniti prima che quelli in riproduzione si esauriscano. Anche con un uso complessivo della CPU basso, il rifornimento può mancare quella scadenza se l'elaborazione audio non è riuscita a essere eseguita in quell'istante o attendeva i dati necessari. Non tutte le interruzioni hanno questa causa, quindi servono anche confronti che cambino dispositivo di uscita e applicazione.

Ingrandire il buffer audio risolve le interruzioni?

Quando il rifornimento è temporaneamente in ritardo, un buffer più grande può assorbirlo. Ma cresce anche l'attesa prima che l'audio accumulato venga riprodotto. Non è un'impostazione che risolve una carenza prolungata di capacità di elaborazione o un dispositivo che si disconnette. Nelle applicazioni e nei driver in cui si può modificare, annotate il valore originale e confrontate un passo alla volta.

A 48 kHz, quanti millisecondi di audio sono 480 frame?

Sono 480 diviso 48000 secondi, cioè 10 millisecondi. Un frame PCM è l'unità che raggruppa i campioni di tutti i canali nello stesso istante. Questo valore è la durata dell'audio che quel numero di frame rappresenta, non la latenza complessiva che comprende dispositivo e applicazione.

Un driver con tempi di esecuzione DPC o ISR lunghi è il colpevole dietro un'interruzione?

È un candidato, ma una classifica basata sul solo tempo di esecuzione non lo stabilisce. 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 di un modulo che un determinato dispositivo o driver sia difettoso, e verificate anche i risultati ottenuti cambiando le condizioni di riproduzione.

Impostare il lettore su priorità in tempo reale migliora le cose?

Non come raccomandazione generale. Alzare la priorità di un thread ordinario non permette di scavalcare DPC e ISR ordinari sulla stessa CPU e non elimina le attese su dati o lock. Chi sviluppa dovrebbe usare meccanismi come MMCSS insieme a una progettazione che non introduca attese nel percorso audio, mentre gli utenti dovrebbero prima confrontare condizioni di riproduzione e percorsi di uscita.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.