Linux PipeWire vs Windows ASIO: mistero (risolto)
@ Bob_Braces
Andare a così basso livello sul funzionamento degli OS non è il mio mestiere.
Ciò detto, da quello che ho capito scontrandomi nel tempo con i problemi audio su linux, in un sistema che usa solo Alsa ogni applicazione ha il suo thread audio con un suo buffer gestito in modo indipendente che entra in competizione con gli altri thread (eventualmente) presenti e questo può provocare instabilità (xruns, crepitii vari, ecc)
Jack crea un layer tra le applicazioni audio e i driver alsa e si preoccupa lui di "dettare legge" gestendo un buffer audio unico per tutti. In pratica fa da orchestratore in modo che non si generino conflitti.
Dopodiché, come dici tu, se hai solo una "cosa" audio che gira (e forse sopra citavi Pianoteq, che è uno dei software audio più robusti con cui mi è capitato di avere a che fare su linux), allora può darsi che non avrai problemi, ma appena la situazione è un po' più complessa, senza jack io non sono mai riuscito a combinare nulla. Citavo una DAW proprio come esempio di software complesso, che magari fa girare più vst, effetti, comunica con l'esterno, ecc.
Magari l'hai già visto, ma qui c'è un documento di design di Jack. Nella sezione "Problem Description" si parla di buffer (in modo sicuramente più appropriato di quanto ho fatto io...)
Grazie! Molto interessante. Non è neanche il mio mestiere, sono un programmatore e saltuariamente ho fatto cose "sporche" con il C e anche con l'audio su Linux, ma non a livello così basso.
Andare a così basso livello sul funzionamento degli OS non è il mio mestiere.
Ciò detto, da quello che ho capito scontrandomi nel tempo con i problemi audio su linux, in un sistema che usa solo Alsa ogni applicazione ha il suo thread audio con un suo buffer gestito in modo indipendente che entra in competizione con gli altri thread (eventualmente) presenti e questo può provocare instabilità (xruns, crepitii vari, ecc)
Jack crea un layer tra le applicazioni audio e i driver alsa e si preoccupa lui di "dettare legge" gestendo un buffer audio unico per tutti. In pratica fa da orchestratore in modo che non si generino conflitti.
Dopodiché, come dici tu, se hai solo una "cosa" audio che gira (e forse sopra citavi Pianoteq, che è uno dei software audio più robusti con cui mi è capitato di avere a che fare su linux), allora può darsi che non avrai problemi, ma appena la situazione è un po' più complessa, senza jack io non sono mai riuscito a combinare nulla. Citavo una DAW proprio come esempio di software complesso, che magari fa girare più vst, effetti, comunica con l'esterno, ecc.
Magari l'hai già visto, ma qui c'è un documento di design di Jack. Nella sezione "Problem Description" si parla di buffer (in modo sicuramente più appropriato di quanto ho fatto io...)
Diciamo che rimane ancora un'area grigia per cui ancora non sono del tutto convinto che nel caso di una singola applicazione audio alla volta vi siano differenze tra ALSA + Jack e solo ALSA, ma approfondirò... Comunque al riguardo della gestione dei thread, proprio per quello è fondamentale assegnare correttamente i privilegi di real time scheduling all'utente; se ben intendo la relativa sezione trova comunque dei limiti nel real time scheduling nel momento in cui (l'unico) processo audio chiede all'OS di allocare memoria (di certo un'operazione notoriamente non deterministica nel tempo), ma se l'app è strutturata bene, dovendo agire in "real time" chiederà di allocare tutta la memoria necessaria all'avvio e mai durante l'esecuzione DSP o comunque durante la gestione dei flussi audio, quindi non mi sembra un problema realmente "collegato"... Sempre se ho interpretato correttamente il testo.
Ko_tatsu ha scritto:
Con 48 però ho 3ms e stabilità, quindi forse sono arrivato allo scioglimento dell'arcano. C'è anche da dire che ho installato una versione RT del kernel
Con 48 però ho 3ms e stabilità, quindi forse sono arrivato allo scioglimento dell'arcano. C'è anche da dire che ho installato una versione RT del kernel
Questa latenza la ottieni con i VI o con l'audio dagli input della scheda? Se si tratta di VI, quali hai usato nel test?
d_phatt ha scritto:
Storicamente Debian è sinonimo di "rock solid"... Ma facci sapere come va
Storicamente Debian è sinonimo di "rock solid"... Ma facci sapere come va
Concordo ma l'aggiornamento da una versione a quella successiva è indolore? Questo è il principale dubbio... detesto dovermi ritrovare al prossimo upgrade con un sistema zoppicante. Ecco allora la mia preferenza per Arch Linux o una derivata, ma felice di essere smentito
Sono un riciclatore hardware seriale, ho sempre adorato Linux perché oltre alla gratuità permette di rispolverare hardware non più supportato da Win-Mac (e scusa se è poco...)
Ovidio ha scritto:
Sono un riciclatore hardware seriale, ho sempre adorato Linux perché oltre alla gratuità permette di rispolverare hardware non più supportato da Win-Mac (e scusa se è poco...)
Sono un riciclatore hardware seriale, ho sempre adorato Linux perché oltre alla gratuità permette di rispolverare hardware non più supportato da Win-Mac (e scusa se è poco...)
Idem, considera che come PC principale ho usato un portatile ASUS dal 2012 fino a maggio 2025 (modificato con RAM aumentata da 4 a 8 giga e disco meccanico sostituito con SSD), poi sostituito da un ThinkPad aziendale riscattato soltanto perché l'ho pagato una miseria, chiaramente è più moderno e performante, la qualità costruttiva è inimitabile, ma l'unico vero upgrade sono state le dimensioni più compatte e il peso minore, perché il vecchio portatile (sebbene ammaccato) ancora funzionava e funziona alla perfezione.
Come fisso invece ho un HP ricondizionato dal 2020 ma era molto più vecchio, anche a quello ho effettuato un upgrade di RAM, SSD e scheda video. E funziona tutt'ora perfettamente. Pagato poco più di 100€ + il costo dei componenti aggiornati che ho descritto.
Ovidio ha scritto:
Concordo ma l'aggiornamento da una versione a quella successiva è indolore? Questo è il principale dubbio... detesto dovermi ritrovare al prossimo upgrade con un sistema zoppicante. Ecco allora la mia preferenza per Arch Linux o una derivata, ma felice di essere smentito
Concordo ma l'aggiornamento da una versione a quella successiva è indolore? Questo è il principale dubbio... detesto dovermi ritrovare al prossimo upgrade con un sistema zoppicante. Ecco allora la mia preferenza per Arch Linux o una derivata, ma felice di essere smentito
Non so cosa intendi per "indolore", per quanto mi riguarda assolutamente sì. Innanzitutto i nuovi rilasci della versione "stable" avvengono a cadenza biennale, quindi una volta aggiornata sei a posto per due anni senza dover fare nessuna modifica sostanziale, gli aggiornamenti riguardano soltanto eventuali bug e problemi di sicurezza, ma le funzionalità sono "congelate", che per me è l'ideale. Puoi fare una partizione Home separata, un tempo io lo facevo ma ora non più, ora quando esce la nuova versione neanche aggiorno, ma la installo proprio da zero e poi faccio un restore dei miei file da uno dei miei backup.
Difficilmente tra una versione maggiore e l'altra ci sono "terremoti", dopo l'installazione configuro GNOME con un paio di estensioni di mio gradimento, reinstallo con APT i programmi che mi servono e via. A fare tutto ciò impiego si e no un paio d'ore ogni due anni, dopodiché se non fai cose strane per i successivi due anni il tempo che devi passare a manutenere il sistema è zero, esegui gli aggiornamenti di sicurezza (ricordando di eseguire un "sudo apt autoremove --purge" ogni tanto per non ingolfare le immagini del kernel) e stop. Zero noie, zero crash, zero cambiamenti di interfaccia o che - puoi concentrarti sul lavorare e basta.
Dopodiché alcuni programmi come l'editor di testo che uso e MuseScore 4 li scarico dai siti ufficiali in versione "portable" sempre aggiornata all'ultima release, li piazzo in una cartella dedicata chiamata "~/Programmi", li integro nel desktop con script di avvio e relativo file .desktop messo in "~/.local/share/applications". L'unica cosa è che sul fisso con scheda video Nvidia e relativo driver ufficiale proprietario MuseScore 4 portable non funziona bene con Wayland, devo switchare su X11 ma si fa con il mouse sulla pagina di login dell'utente con due click... Non c'è neanche bisogno di riavviare. Ecco questo è quanto di più grave mi sia successo in credo 10 anni di utilizzo... E comunque il workaround, una volta compresa la causa del problema, è stato banale.
@ Ovidio
Questa latenza la ottieni con i VI o con l'audio dagli input della scheda? Se si tratta di VI, quali hai usato nel test?
Allora, tieni conto che questa latenza l'ho misurata proprio registrando manualmente un round trip di un impulso tirando un cavo dall'out della scheda audio all'in. Di conseguenza questo numero contiene latenza in entrata + latenza in uscita. I VI, al netto della latenza del messaggio MIDI (che non è indifferente ma non l'ho misurata nel mio test), hanno ovviamente solo la latenza in uscita.
Ko_tatsu ha scritto:
Con 48 però ho 3ms e stabilità, quindi forse sono arrivato allo scioglimento dell'arcano. C'è anche da dire che ho installato una versione RT del kernel
Con 48 però ho 3ms e stabilità, quindi forse sono arrivato allo scioglimento dell'arcano. C'è anche da dire che ho installato una versione RT del kernel
Questa latenza la ottieni con i VI o con l'audio dagli input della scheda? Se si tratta di VI, quali hai usato nel test?
Come ho detto, ho dovuto un po' smanettare nel file config di WirePlumber perchè di fatto anche settando la block size del device nei vari software, per qualche motivo che ad ora ignoro, WirePlumber "passava" l'audio tra i vari processi con un'altra block size (almeno, questo è quanto mi sembra di aver capito).
Comunque rispetto a un altro messaggio che avevi inviato: CachyOS essendo basata su Arch ha un modello "rolling release" quindi tecnicamente qualche update potrebbe rompere qualcosa. Non è detto che succeda, anzi, ma se vuoi proprio scongiurare a tutti i costi questo rischio puoi usare AV Linux (che prima o poi vorrei provare), pensata esplicitamente per l'audio e basata su Debian
