La distorsione audio su Ubuntu 24.04 può derivare da diversi fattori: l'applicazione, PipeWire, WirePlumber, ALSA, il driver del kernel o l'hardware audio stesso. L'approccio più pratico consiste nell'identificare prima il dispositivo interessato, quindi modificare un buffer o un'impostazione del dispositivo alla volta. Su un desktop Ubuntu 24.04 standard, PipeWire si trova al di sopra di ALSA e WirePlumber gestisce i dispositivi ALSA, quindi la maggior parte degli utenti dovrebbe ottimizzare le proprietà ALSA esposte tramite WirePlumber prima di sostituire la configurazione ALSA predefinita del sistema.
Ubuntu 24.04 originariamente includeva PipeWire 1.0.4 e gli attuali pacchetti Noble di Ubuntu continuano a utilizzare WirePlumber 0.4.17 anziché il formato di configurazione più recente della versione 0.5. Questo dettaglio sulla versione è importante perché WirePlumber 0.4 utilizza frammenti Lua ~/.config/wireplumber/main.lua.d/. La wireplumber.conf.dsintassi più recente che potresti trovare nella documentazione ufficiale si applica a WirePlumber 0.5 e versioni successive. Verifica la versione installata prima di copiare qualsiasi configurazione.
Riferimenti ufficiali: note di rilascio di Ubuntu 24.04 LTS , pacchetto WirePlumber di Ubuntu per gli aggiornamenti di Noble , riferimento alla configurazione di WirePlumber 0.4 ALSA e riferimento al plugin ALSA PCM .
Guida rapida: cosa provare per primo
| Sintomo | Prima verifica pratica | Possibile modifica |
| Crepitio sotto carico della CPU | Conferma il lavandino corretto e fai attenzione alle interruzioni. | Prova una dimensione del periodo ALSA maggiore, ad esempio 1024 o 1048 fotogrammi. |
| Distorsione presente solo su un DAC USB | Identificare il nodo ALSA/PipeWire esatto | Applica la regola solo a quel nodo; evita una regola globale |
| Rumore quando un dispositivo si riattiva dalla modalità inattiva | Riproduci dopo alcuni secondi di silenzio | Aumenta o disattiva il timeout di sospensione per quel nodo specifico |
| Problemi in un'applicazione legacy che utilizza solo ALSA | Prova l'app con aplayo un PCM esplicito | Utilizzare un per utente ~/.asoundrccon plug/dmix |
| Distorsione a una frequenza di campionamento | Test del materiale a 44,1 kHz e 48 kHz | Preferisci una frequenza di campionamento supportata dall'hardware e lascia che PipeWire ricampiona quando necessario. |
1. Identificare l'hardware ALSA e lo stack audio
Iniziate elencando i dispositivi di riproduzione e verificando quale server audio è attivo. Non date per scontato che hw:0,0si tratti degli altoparlanti; le schede HDMI, le cuffie USB, le webcam e le docking station possono cambiare numero di scheda tra un avvio e l'altro.
aplay -l
wpctl status
pactl info
wireplumber --version
pipewire --version
Didascalia: L' aplay -lelenco separa il dispositivo di riproduzione analogica integrato dall'HDMI, il che aiuta a evitare di applicare una modifica ALSA alla scheda sbagliata.
Se pactl infoviene visualizzato "PulseAudio (su PipeWire)", è normale su Ubuntu 24.04. L'interfaccia compatibile con PulseAudio viene fornita da PipeWire. Su Ubuntu 24.04/Noble standard, wireplumber --versiondovrebbe normalmente essere visualizzata la serie 0.4.x, a meno che non sia stata installata una build diversa.
2. Verificare la distorsione prima di modificare la configurazione
Utilizza un test ripetibile anziché valutare i cambiamenti basandoti su video web casuali. Un breve file WAV speaker-testo una traccia musicale nota rendono i confronti prima/dopo più significativi. Verifica inoltre se il problema si presenta in egual misura su uscita analogica, HDMI, Bluetooth e USB. Se solo un percorso è interessato, concentra la soluzione su quel percorso specifico.
speaker-test -c 2 -t wav
aplay /usr/share/sounds/alsa/Front_Center.wav
Per i dispositivi USB, il kernel espone le informazioni di flusso in /proc/asound/. Il percorso esatto varia a seconda della scheda, quindi è consigliabile controllare /proc/asound/cardsprima di copiare ciecamente il numero della scheda.
Didascalia: Le informazioni di flusso ALSA possono rivelare la frequenza di campionamento attiva, il numero di canali e il formato di campionamento per un flusso di riproduzione; il numero della scheda dipende dall'hardware.
3. Eseguire il backup della configurazione utente corrente
Prima di apportare qualsiasi modifica, conserva tutte le sovrascritture ALSA o WirePlumber esistenti. Le modifiche a livello utente sono più sicure rispetto alla modifica dei file nella directory /usr/share, perché gli aggiornamenti dei pacchetti possono sostituire i file di sistema.
cp -a ~/.asoundrc ~/.asoundrc.backup 2>/dev/null || true
mkdir -p ~/.config/wireplumber/main.lua.d
cp -a ~/.config/wireplumber/main.lua.d ~/.config/wireplumber/main.lua.d.backup 2>/dev/null || true
Se in precedenza hai copiato una configurazione da una guida scritta per WirePlumber 0.5, rimuovila o spostala prima di testarla su Ubuntu 24.04 standard. WirePlumber 0.4 e 0.5 utilizzano formati di configurazione diversi.
4. Regola il comportamento del buffer ALSA tramite WirePlumber 0.4
Su Ubuntu 24.04, questa è solitamente la modifica a livello ALSA più rilevante perché WirePlumber crea e configura i nodi PipeWire supportati da ALSA. La documentazione di WirePlumber descrive api.alsa.period-sizela dimensione del periodo in campioni e api.alsa.headroomcome buffer aggiuntivo tra puntatori hardware e software. La maggior parte dei dispositivi USB viene trattata come dispositivi batch e la dimensione del periodo influisce sia sulla frequenza di interruzione che sul comportamento del buffer.
Crea una regola utente:
nano ~/.config/wireplumber/main.lua.d/51-alsa-tuning.lua
Utilizza una regola che si rivolga solo al nodo di output problematico. Per prima cosa ottieni il nome del nodo con wpctl statuso pw-cli list-objects Node. Quindi adatta questo esempio:
local rule = {
matches = {
{
{ "node.name", "matches", "alsa_output.*" },
},
},
apply_properties = {
["api.alsa.period-size"] = 1024,
["api.alsa.headroom"] = 0,
},
}
table.insert(alsa_monitor.rules, rule)
Non considerare 1024 come un valore magico universale. Si tratta di un punto di prova conservativo. Se la distorsione persiste, confronta 512, 1024 e 2048 uno alla volta. Periodi più lunghi possono migliorare la tolleranza ai ritardi di pianificazione su alcuni sistemi, ma aumentano la latenza; periodi più brevi possono ridurre la latenza, ma aumentano la frequenza degli interrupt e potrebbero evidenziare underrun su una macchina sotto stress. Mantieni il valore più piccolo che rimane stabile per il tuo carico di lavoro.
Se il dispositivo presenta I/O mappati in memoria danneggiati, WirePlumber espone anche api.alsa.disable-mmap. La documentazione ufficiale descrive esplicitamente questa opzione come un fallback di compatibilità e osserva che l'accesso in lettura/scrittura è più lento, quindi non abilitarla a meno che la distorsione non sia chiaramente correlata al comportamento di mmap.
["api.alsa.disable-mmap"] = true,
Un'altra opzione specifica del dispositivo è session.suspend-timeout-seconds. Se un DAC produce rumori o distorsioni ogni volta che si riattiva, testare un timeout più lungo, o 0disabilitare la sospensione per quel nodo, può aiutare a isolare la causa. Disabilitare la sospensione mantiene il dispositivo ALSA occupato, quindi è un compromesso piuttosto che una raccomandazione predefinita.
5. Utilizzare .asoundrc solo quando l'applicazione utilizza effettivamente ALSA direttamente
Un PCM per utente ~/.asoundrcpuò essere utile per le applicazioni meno recenti che bypassano PipeWire e aprono direttamente i PCM ALSA. Può anche essere utile per testare il comportamento di una frequenza di campionamento fissa o del mixaggio software. Tuttavia, sovrascrivere l'impostazione predefinita ALSA a livello globale può interferire con il plugin ALSA di PipeWire, quindi è consigliabile utilizzare un PCM denominato quando possibile, anziché sostituire pcm.!default.
Ad esempio, dmixil plugin di ALSA supporta valori espliciti di rate, period_size, e buffer_size. Un PCM di test denominato può apparire così:
pcm.stable_test {
type plug
slave.pcm "stable_dmix"
}
pcm.stable_dmix {
type dmix
ipc_key 2048
ipc_key_add_uid true
slave {
pcm "hw:0,0"
rate 48000
period_time 0
period_size 1024
buffer_size 4096
}
}
Sostituisci hw:0,0con la scheda e il dispositivo effettivi da aplay -l. Quindi esegui un test senza modificare le impostazioni predefinite del sistema:
aplay -D stable_test /usr/share/sounds/alsa/Front_Center.wav
Didascalia: Per ciascun utente .asoundrcè possibile definire parametri ALSA fissi per test controllati; l'utilizzo di un hwtarget diretto deve essere effettuato con cautela poiché bypassa la conversione automatica del formato.
Il progetto ALSA fa notare che dmixha una configurazione di base fissa a meno che non si specifichino valori nella sua definizione slave, mentre il plugplugin può eseguire la conversione di formato e frequenza. Ecco perché combinare un plugPCM denominato con un dmixPCM sintonizzato separatamente è più sicuro per gli esperimenti rispetto a forzare ogni programma ad aprire direttamente l'hardware grezzo.
6. Riavviare i servizi audio utente e riprovare
Dopo aver modificato la regola di WirePlumber, riavviare lo stack audio utente. Chiudere prima le applicazioni che stanno utilizzando attivamente l'audio.
systemctl --user restart wireplumber pipewire pipewire-pulse
Ripeti quindi lo stesso materiale di prova utilizzato prima della modifica. Apri Impostazioni > Suono e assicurati che il dispositivo di output e il profilo previsti siano ancora selezionati.
Didascalia: Dopo aver riavviato i servizi audio, verificare che Ubuntu selezioni ancora il dispositivo di output e il profilo desiderati prima di valutare se la distorsione è stata risolta.
Come valutare se la modifica ha funzionato
- Lo stesso file di test viene riprodotto ripetutamente senza crepitii, ronzii, distorsioni o brevi interruzioni.
- La distorsione non si ripresenta dopo che il dispositivo è rimasto inattivo e si è riattivato.
- Le normali applicazioni desktop, i browser e le videochiamate continuano a utilizzare il dispositivo di output previsto.
- La latenza rimane accettabile per il tuo caso d'uso; la riproduzione musicale può tollerare un buffering maggiore rispetto al monitoraggio in diretta o ai videogiochi.
- La soluzione rimane stabile anche dopo aver effettuato il logout e il successivo accesso o dopo aver riavviato il sistema.
Quando le modifiche ad ALSA non sono la soluzione giusta
Non continuare ad aumentare i buffer se il sintomo è chiaramente dovuto a clipping hardware, un cavo allentato, un ingresso analogico sovraccarico, un hub USB difettoso o un altoparlante di scarsa qualità. Controlla anche i livelli del mixer alsamixer; la distorsione che si verifica solo vicino al 100% del volume può essere correlata al guadagno piuttosto che a un problema di programmazione.
Se il problema è iniziato dopo un aggiornamento del kernel o del firmware, prova un altro kernel supportato dal menu GRUB prima di creare regole audio sempre più complesse. Se è interessato solo il Bluetooth, concentrati sul codec/profilo Bluetooth piuttosto che sulle impostazioni del periodo ALSA. Se è interessato solo l'HDMI, verifica prima il profilo HDMI e il ricevitore/monitor.
Lista di controllo per il rollback
- Rimuovere o rinominare
~/.config/wireplumber/main.lua.d/51-alsa-tuning.lua.
- Ripristina
~/.asoundrcdal backup oppure elimina il file di sola prova.
- Riavvia
wireplumber, pipewire, e pipewire-pulse.
- Eseguire nuovamente il comando
wpctl statusper speaker-testconfermare che il comportamento predefinito sia stato ripristinato.
In conclusione
Per Ubuntu 24.04, iniziate con regole ALSA WirePlumber 0.4 mirate anziché con una .asoundrcsostituzione generalizzata a livello di sistema. Identificate il nodo di output esatto, modificate una proprietà alla volta e confrontate lo stesso audio di test dopo ogni modifica. Una dimensione del periodo come 1024 è un buon punto di partenza per la diagnosi, ma il valore corretto dipende dal dispositivo e dal carico di lavoro. Riservate disable-mmaple modifiche di sospensione e dmixi PCM personalizzati ai casi in cui i vostri test indichino specificamente tali comportamenti.