Vediamo come qualcosa di apparentemente completamente separato dall'audio può influenzare la nostra esperienza d'ascolto.
Salve a tutti. È passato un po' di tempo, eh?
Volevo scrivere questo post un paio di settimane fa, ma non ho mai trovato l'energia per farlo (viva il lavorare fino allo sfinimento!).
Oggi daremo un'occhiata a come sono riuscito a trovare la fonte di un problema estremamente annoso con l'audio del mio portatile, il processo di ricerca e debug e la mia estrema sorpresa nel vedere il risultato.
Il problema
Da quando sono passato a Pipewire 0.3.x sono stato vittima di un problema estremamente fastidioso: ogni volta che usavo qualsiasi cosa basata sulla tecnologia WebRTC (quindi Jitsi, Google Meet, Discord, Telegram...) il mio audio iniziava a dar problemi. Finivo per avere l'ultima lettera di una frase precedente che veniva ripetuta, scricchiolii, pop, salti: l'intero pacchetto.
Mi faceva infuriare :
La non-soluzione
Ho contattato la gente di Freedesktop tramite il logo GitLab per vedere cosa si potesse fare, perchè non avevo notato alcun problema del genere nel ramo 0.2.x di Pipewire e nemmeno in Pulseaudio.
Ho provato a seguire tutte le soluzioni standard: cancellare qualunque configurazione non predefinita, installare rtkit ed attivare i privilegi realtime, nulla.
Il team di Pipewire mi ha suggerito di aumentare il quantum minimo consentito, il che ha fortemente migliorato la situazione a prima vista, ma in realtà ha portato ad un sacco di altri problemi.
Aumentare il quantum minimo vuol dire che i programmi avevano più latenza, portando i programmi WebRTC a rompersi completamente dopo una decina di minuti di chiamata: dopo un po' non sentivo più nessuno parlare.
Il debug
Ho litigato con questo problema per quasi un anno, a salti, con un periodo nel mezzo (di circa 4 mesi) dove mi sono arreso al mio futuro scricchioloso.
Questo fino a circa 3 settimane fa, quando sono diventato "estremamente sovra-infastidito" dal problema ed ho deciso di ricontattare il team di Pipewire: mi è stato suggerito di provare dell'hardware diverso e/o una distro differente. C'erano solo due possibilità: il mio portatile o il mio sistema operativo.
Ho tentato di creare un caso di test quanto più facilmente riproducibile possibile, che è risultato essenzialmente nel riprodurre una certa canzone tramite MPV mentre
pavucontrol
era aperto. Questo veniva mostrato dal numero nella colonna "ERR" in
pw-top
che aumentava spesso, così come dagli scricchiolii.
Ho provato ad usare hardware differente (con un piccolo mixer usato come scheda audio esterna) senza risultato, poi ho provato ad usare una Live di Ubuntu da chiavetta USB e mi sono reso conto che in questo caso non c'erano scricchiolii.
Il mio portatile era a posto, il che vuol dire che il problema è la mia distro a la mia configurazione.
A quel punto il mio collega di lavoro lancia un'idea: chiudi tutto quello che non è utile per l'audio e per la "sopravvivenza" del sistema, e vedi cosa accade.
Ho chiuso tutto : servizi, demoni, la barra degli strumenti... Eravamo rimasti solo io, Pipewire ed il mio manager di finestre (openbox). Nessun scricchiolio.
Ecco la mia pista.
La causa
Mentre ero in chiamata col mio collega (tramite cellulare), lui si è lamentato che il suo Conky stava avendo dei problemi. Questo mi ha ricordato che fra le tante cose da riaprire (per i miei test) c'era Conky ed all'improvviso... gli scricchiolii sono tornati.
Chiudo Conky, gli scricchiolii spariscono, lo riavvio e ritornano.
Abbiamo trovato la causa degli scricchiolii, ma perchè? Perchè un monitor di sistema dovrebbe influenzare così tanto l'audio?
Andando più a fondo
Ho deciso di riavviare il mio portatile per avere una situazione più usabile, chiudendo Conky ed assicurandomi che l'audio stesse funzionando come dovuto.
Era ora di capire cosa stava succedendo.
Ho provato a cambiare alcune impostazioni base che potrebbero aver messo in difficoltà il mio laptop, come trasparenza e double-buffering, senza alcun risultato. Ho cambiato l'intervallo usato da Conky per aggiornarsi, da 2 secondi ad 1 secondo. Gli scricchiolii sono peggiorati un sacco .
Conky stava eseguendo un comando che causava il problema audio. Era ora di una buona "ricerca binaria": ho commentato metà della mia configurazione Conky e riprovato.
Purtroppo commentare la prima metà della configurazione non è bastato per far sparire il problema, quindi l'ho ripristinata ed ho commentato la seconda metà. Gli scricchiolii sono spariti.
La mia configurazione di Conky è abbastanza corta che da lì in poi ho semplicemente potuto commentare i comandi uno ad uno. Fino a quando non sono arrivato a
${i8k_cpu_temp}
. Il fatto che Conky stesse rilevando la temperatura del mio processore stava causando problemi all'audio.
Per esserne sicuro, ho chiuso Conky e verificato il manuale, dove dice che il comando
${i8k_cpu_temp}
legge la temperatura da
/proc/i8k
. Ho deciso di provare ad usare
cat /proc/i8k
mentre ascoltavo musica: l'audio distorceva ogni volta che eseguivo quel comando.
Ho trovato il colpevole.
La motivazione
Perchè verificare la temperatura del processore dovrebbe distorcere l'audio? La risposta è stata ipotizzata dal team di Pipewire quando ho riportato i risultati delle mie analisi, e poi confermato da me dopo aver letto cos'è i8k (descrizione dalla pagina https://github.com/lochotzke/i8k ):
Linux driver for accessing the SMM BIOS on Dell Laptops
SMM significa "System Management Mode" (A volte conosciuto come "Ring -2"), una modalità dove la normale esecuzione dei programmi incluso il sistema operativo è sospesa mentre un programma nel firmware del computer viene eseguito.
Questo vuol dire che ogni volta che il mio Conky controllava la temperatura del processore (ogni due secondi), stavo in realtà bloccando l'intero sistema operativo per quel (poco) tempo necessario per acquisire la temperatura.
Sono rimasto allibito.
Ecco cosa succede quando vado ad usare un comando per controllare la temperatura del processore senza verificarne gli effetti collaterali.
E dopo tutto questo casino mi rendo pure conto che la temperatura era pure sbagliata!
Il "dopo"
Ho inviato la mia soluzione al GitLab di Pipewire, oltre che nel forum della mia distro Linux (dove sembra che abbia risolto i problemi audio di un'altra persona!), ringraziando tutti per la loro pazienza ed aiuto.
Ora il mio audio funziona alla grande e posso godermi la musica senza problemi, anche con una chiamata WebRTC aperta, mentre aspetto che altre persone si uniscano.
Spero questo possa aiutare altra gente nel caso si ritrovino in una situazione simile.
Grazie a tutti per aver letto questo post.
Penaz.