Linux PipeWire vs Windows ASIO: mistero
Buongiorno! Domanda un po' da nerd per quei (pochi) disgraziati che usano Linux per i loro sporchi fini musicali e/o per addetti ai lavori che ci capiscono più di me:
Ho da poco installato Linux (con distro CachyOS) sul mio laptop in dual boot con windows per "vedere di nascosto l'effetto che fa" e valutare se effettivamente i driver audio di Linux (e in particolare PipeWire, costruito sopra ALSA) effettivamente diano latenza minore a parità di frequenza di campionamento e dimensione del vettore rispetto ai vari gusti di ASIO per Windows.
Ho provato a misurare in maniera molto barbara (tirando un cavo dall'output all'input della scheda) la round trip latency (RTL) della mia Focusrite 2i4 2nd gen (USB 2.0) e su Windows con sampling rate a 48 kHz e block size di 64 risulta una latenza di 7ms (accurata rispetto alla stima data dal software di impostazioni del driver). Installato Linux, ho notato che PipeWire riportava una latenza di 1.3 ms a parità di sampling rate e dimensione del vettore. Estasiato, ho rifatto il test audio... per misurare una latenza di 6 ms e qualche nocciolina
Ora, comprendo che le stime di PipeWire non siano ovviamente reali e non tengano conto ad esempio della velocità della USB; mi sembra però che farsi tutto 'sto accollo per 1ms di differenza di latenza suggerisca che mi stia perdendo qualcosa per strada
Chiedo scusa per il quesito piuttosto di nicchia... i sw di produzione musicale sono l'unica cosa che mi tiene prigionier... ehm, utente di Windows
Ho da poco installato Linux (con distro CachyOS) sul mio laptop in dual boot con windows per "vedere di nascosto l'effetto che fa" e valutare se effettivamente i driver audio di Linux (e in particolare PipeWire, costruito sopra ALSA) effettivamente diano latenza minore a parità di frequenza di campionamento e dimensione del vettore rispetto ai vari gusti di ASIO per Windows.
Ho provato a misurare in maniera molto barbara (tirando un cavo dall'output all'input della scheda) la round trip latency (RTL) della mia Focusrite 2i4 2nd gen (USB 2.0) e su Windows con sampling rate a 48 kHz e block size di 64 risulta una latenza di 7ms (accurata rispetto alla stima data dal software di impostazioni del driver). Installato Linux, ho notato che PipeWire riportava una latenza di 1.3 ms a parità di sampling rate e dimensione del vettore. Estasiato, ho rifatto il test audio... per misurare una latenza di 6 ms e qualche nocciolina
Ora, comprendo che le stime di PipeWire non siano ovviamente reali e non tengano conto ad esempio della velocità della USB; mi sembra però che farsi tutto 'sto accollo per 1ms di differenza di latenza suggerisca che mi stia perdendo qualcosa per strada
Chiedo scusa per il quesito piuttosto di nicchia... i sw di produzione musicale sono l'unica cosa che mi tiene prigionier... ehm, utente di Windows
beefolco 18-03-26 17.32
@ Ko_tatsu
Buongiorno! Domanda un po' da nerd per quei (pochi) disgraziati che usano Linux per i loro sporchi fini musicali e/o per addetti ai lavori che ci capiscono più di me:
Ho da poco installato Linux (con distro CachyOS) sul mio laptop in dual boot con windows per "vedere di nascosto l'effetto che fa" e valutare se effettivamente i driver audio di Linux (e in particolare PipeWire, costruito sopra ALSA) effettivamente diano latenza minore a parità di frequenza di campionamento e dimensione del vettore rispetto ai vari gusti di ASIO per Windows.
Ho provato a misurare in maniera molto barbara (tirando un cavo dall'output all'input della scheda) la round trip latency (RTL) della mia Focusrite 2i4 2nd gen (USB 2.0) e su Windows con sampling rate a 48 kHz e block size di 64 risulta una latenza di 7ms (accurata rispetto alla stima data dal software di impostazioni del driver). Installato Linux, ho notato che PipeWire riportava una latenza di 1.3 ms a parità di sampling rate e dimensione del vettore. Estasiato, ho rifatto il test audio... per misurare una latenza di 6 ms e qualche nocciolina
Ora, comprendo che le stime di PipeWire non siano ovviamente reali e non tengano conto ad esempio della velocità della USB; mi sembra però che farsi tutto 'sto accollo per 1ms di differenza di latenza suggerisca che mi stia perdendo qualcosa per strada
Chiedo scusa per il quesito piuttosto di nicchia... i sw di produzione musicale sono l'unica cosa che mi tiene prigionier... ehm, utente di Windows
Buongiorno, premetto che non conosco la distribuzione che stai usando, uso Debian con KxStudio per i miei sporchi fini.
Buongiorno! Domanda un po' da nerd per quei (pochi) disgraziati che usano Linux per i loro sporchi fini musicali e/o per addetti ai lavori che ci capiscono più di me:
Ho da poco installato Linux (con distro CachyOS) sul mio laptop in dual boot con windows per "vedere di nascosto l'effetto che fa" e valutare se effettivamente i driver audio di Linux (e in particolare PipeWire, costruito sopra ALSA) effettivamente diano latenza minore a parità di frequenza di campionamento e dimensione del vettore rispetto ai vari gusti di ASIO per Windows.
Ho provato a misurare in maniera molto barbara (tirando un cavo dall'output all'input della scheda) la round trip latency (RTL) della mia Focusrite 2i4 2nd gen (USB 2.0) e su Windows con sampling rate a 48 kHz e block size di 64 risulta una latenza di 7ms (accurata rispetto alla stima data dal software di impostazioni del driver). Installato Linux, ho notato che PipeWire riportava una latenza di 1.3 ms a parità di sampling rate e dimensione del vettore. Estasiato, ho rifatto il test audio... per misurare una latenza di 6 ms e qualche nocciolina
Ora, comprendo che le stime di PipeWire non siano ovviamente reali e non tengano conto ad esempio della velocità della USB; mi sembra però che farsi tutto 'sto accollo per 1ms di differenza di latenza suggerisca che mi stia perdendo qualcosa per strada
Chiedo scusa per il quesito piuttosto di nicchia... i sw di produzione musicale sono l'unica cosa che mi tiene prigionier... ehm, utente di Windows
Dovresti confontare ASIO con jack più che con pipewire. in jack puoi regolare la dimensione ed il numero dei buffer come faresti in con asio su windows così da impostare la latenza a piacimento. Tutte le applicazioni musicali per linux che conosco supportano jack.
@ beefolco
Buongiorno, premetto che non conosco la distribuzione che stai usando, uso Debian con KxStudio per i miei sporchi fini.
Dovresti confontare ASIO con jack più che con pipewire. in jack puoi regolare la dimensione ed il numero dei buffer come faresti in con asio su windows così da impostare la latenza a piacimento. Tutte le applicazioni musicali per linux che conosco supportano jack.
Grazie per la risposta! Ho in realtà installato pipewire-jack che dovrebbe contenere sia PipeWire che JACK. Tecnicamente PipeWire dovrebbe aver rimpiazzato sia JACK che PulseAudio, quindi mi aspetterei che in termini di efficienza siano simili. Magari faccio la prova con jack2 e rimisuro Buongiorno, premetto che non conosco la distribuzione che stai usando, uso Debian con KxStudio per i miei sporchi fini.
Dovresti confontare ASIO con jack più che con pipewire. in jack puoi regolare la dimensione ed il numero dei buffer come faresti in con asio su windows così da impostare la latenza a piacimento. Tutte le applicazioni musicali per linux che conosco supportano jack.
Intanto ho ottenuto qualche risultato modificando le impostazioni di WirePlumber. Settando la dimensione del vettore a 32 riesco ad avere 2ms di RTL ma è un dropout continua
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
Ko_tatsu ha scritto:
Tecnicamente PipeWire dovrebbe aver rimpiazzato sia JACK che PulseAudio
Tecnicamente PipeWire dovrebbe aver rimpiazzato sia JACK che PulseAudio
Si, in un certo senso unifica un po' tutto il marasma tra ALSA, PulseAudio e JACKD.
Ko_tatsu ha scritto:
Ho in realtà installato pipewire-jack che dovrebbe contenere sia PipeWire che JACK
Ho in realtà installato pipewire-jack che dovrebbe contenere sia PipeWire che JACK
No, in realtà ti permette di usare programmi che supportano JACK in Pipewire. Poi sta a te configurarlo per configurare robe tipo latenza e samplerate, ma hai un vantaggio grosso di non dover per esempio terminare JACK per sentire, che so, un video su YouTube.
Personalmente sto approfondendo ma ho trovato JACK più maturo in alcuni sensi per le applicazioni professionali. Forse è perchè lo conosco meglio di Pipewire e quindi son riuscito a tirar fuori migliori risultati
P.S. Benvenuto al lato oscuro
Ormai Windows lo userò solo sul portatile del lavoro
GianfrixMG ha scritto:
Personalmente sto approfondendo ma ho trovato JACK più maturo in alcuni sensi per le applicazioni professionali. Forse è perchè lo conosco meglio di Pipewire e quindi son riuscito a tirar fuori migliori risultati
Personalmente sto approfondendo ma ho trovato JACK più maturo in alcuni sensi per le applicazioni professionali. Forse è perchè lo conosco meglio di Pipewire e quindi son riuscito a tirar fuori migliori risultati
Sottoscrivo. Dopo mooolti anni di amore/odio con JACK da qualche mese ho provato a fare il salto su Pipewire, almeno su uno dei laptop ad uso generico che ho e confermo che software come Waveform o GrandOrgue o Carla non hanno il supporto nativo e occorre usare pw-jack. Io per comodità mi sono fatto uno script di una riga ignorantissimo che prende in input il programma da lanciare fatto così
PIPEWIRE_LATENCY="256/48000" pw-jack $1 & (256/48000 sono valori che vanno bene nel mio caso)
Solo per GrandOrgue ho fatto una cosa più complessa per scegliere che scheda audio usare, come mappare il midi ecc.
@ GianfrixMG
Si, in un certo senso unifica un po' tutto il marasma tra ALSA, PulseAudio e JACKD.
No, in realtà ti permette di usare programmi che supportano JACK in Pipewire. Poi sta a te configurarlo per configurare robe tipo latenza e samplerate, ma hai un vantaggio grosso di non dover per esempio terminare JACK per sentire, che so, un video su YouTube.
Personalmente sto approfondendo ma ho trovato JACK più maturo in alcuni sensi per le applicazioni professionali. Forse è perchè lo conosco meglio di Pipewire e quindi son riuscito a tirar fuori migliori risultati
P.S. Benvenuto al lato oscuro Ormai Windows lo userò solo sul portatile del lavoro
Grazie della chiarificazione! È un po' disorientante in effetti venendo da fuori Ko_tatsu ha scritto:
Tecnicamente PipeWire dovrebbe aver rimpiazzato sia JACK che PulseAudio
Tecnicamente PipeWire dovrebbe aver rimpiazzato sia JACK che PulseAudio
Si, in un certo senso unifica un po' tutto il marasma tra ALSA, PulseAudio e JACKD.
Ko_tatsu ha scritto:
Ho in realtà installato pipewire-jack che dovrebbe contenere sia PipeWire che JACK
Ho in realtà installato pipewire-jack che dovrebbe contenere sia PipeWire che JACK
No, in realtà ti permette di usare programmi che supportano JACK in Pipewire. Poi sta a te configurarlo per configurare robe tipo latenza e samplerate, ma hai un vantaggio grosso di non dover per esempio terminare JACK per sentire, che so, un video su YouTube.
Personalmente sto approfondendo ma ho trovato JACK più maturo in alcuni sensi per le applicazioni professionali. Forse è perchè lo conosco meglio di Pipewire e quindi son riuscito a tirar fuori migliori risultati
P.S. Benvenuto al lato oscuro
Ormai Windows lo userò solo sul portatile del lavoro
Comunque sì, mi sono buttato abbastanza su PipeWire perché avevo già messo gli occhi su BitWig (e supercollider che uso già su win) che lo supporta nativamente. Inoltre nella distro che ho usato (una variante di Archlinux) era già setuppato.
Ho strizzato al massimo la spugna nel file di configurazione di wireplumber che a quanto pare è l'unico modo di settare i parametri del dispositivo audio a basso livello. Tutto questo per un guadagno netto di 4ms di latenza
Mi sto informando un po' effettivamente su JACK e sul suo ruolo nei kernel real time, ma a quanto ho capito pipewire è già stabile e tendenzialmente più usabile (come giustamente dicevi eviti anche di doverlo usare esclusivamente per ogni applicazione). Ci sono opinioni molto forti in merito se si guarda online ma a quanto ho capito è tipico
Se non fosse per Ableton e Max/MSP avrei già fatto il salto a Linux da tempo, il mio Thinkpad del 2019 è risorto a nuova vita
Un po' di chiarezza sull'audio in Linux (anche per chi magari legge e segue senza intervenire, più che per coloro già ben avvezzi):
- ALSA: sottosistema audio del kernel Linux che è alla base di tutto il resto, gestisce l'interfacciamento con l'hardware audio e rappresenta quindi le fondamenta di ogni altra cosa in ambito audio su Linux; non è "in concorrenza" con niente, in quanto i vari sound server PulseAudio, JACK e PipeWire sono costruiti su di esso.
- PipeWire è ormai stabile (almeno per la mia esperienza, non l'ho smanettato, lo "uso" e basta, ma la sua inclusione in Debian 12 e 13 lo conferma) e largamente utilizzato in moltissime distribuzioni. Nasce per unificare i casi d'uso di PulseAudio (audio "consumer") e JACK (audio "pro" low latency) in unico sound server, sempre basato su ALSA. Ha praticamente cancellato PulseAudio dalla faccia della terra, non so JACK.
- JACK: soppiantato o meno da PipeWire che sia, chiariamo che serviva a far comunicare più applicazioni audio/MIDI tra loro facendole scambiare flussi di dati a bassa latenza, ma non è (né era) assolutamente necessario nel momento in cui si usa una sola applicazione audio alla volta! È/era praticamente l'analogo del ReWire su Windows, ve lo ricordate?
Correggetemi se sbaglio, ma la cosa più diretta e con meno latenza e meno "giri" è utilizzare direttamente ALSA come sistema audio, a meno di non dover far comunicare ad esempio l'uscita MIDI di un sequencer esterno con una DAW... Ma ormai i sequencer sono tutti integrati nelle DAW.
- ALSA: sottosistema audio del kernel Linux che è alla base di tutto il resto, gestisce l'interfacciamento con l'hardware audio e rappresenta quindi le fondamenta di ogni altra cosa in ambito audio su Linux; non è "in concorrenza" con niente, in quanto i vari sound server PulseAudio, JACK e PipeWire sono costruiti su di esso.
- PipeWire è ormai stabile (almeno per la mia esperienza, non l'ho smanettato, lo "uso" e basta, ma la sua inclusione in Debian 12 e 13 lo conferma) e largamente utilizzato in moltissime distribuzioni. Nasce per unificare i casi d'uso di PulseAudio (audio "consumer") e JACK (audio "pro" low latency) in unico sound server, sempre basato su ALSA. Ha praticamente cancellato PulseAudio dalla faccia della terra, non so JACK.
- JACK: soppiantato o meno da PipeWire che sia, chiariamo che serviva a far comunicare più applicazioni audio/MIDI tra loro facendole scambiare flussi di dati a bassa latenza, ma non è (né era) assolutamente necessario nel momento in cui si usa una sola applicazione audio alla volta! È/era praticamente l'analogo del ReWire su Windows, ve lo ricordate?
Correggetemi se sbaglio, ma la cosa più diretta e con meno latenza e meno "giri" è utilizzare direttamente ALSA come sistema audio, a meno di non dover far comunicare ad esempio l'uscita MIDI di un sequencer esterno con una DAW... Ma ormai i sequencer sono tutti integrati nelle DAW.
- Kernel RT: non era davvero necessario per l'audio "pro" su Linux, quello che è davvero importante, anzi fondamentale, è assegnare all'utente i privilegi di real time scheduling, che una volta modificati richiedono un riavvio e nulla più. Inoltre le ultime release di Linux hanno totalmente integrato le caratteristiche real time nella versione standard del kernel (gestendo e superando complessità enormi, questa è gente con gli attributi cubici), quindi non ci sarà più una separazione tra il kernel real time e quello "normale" - quello "normale" potrà funzionare anche in modalità real time.
Motivo per cui la situazione non lascia molto spazio a discussioni e flame war, è piuttosto oggettivo lo stato (eccellente) delle cose.
Però una cosa "soggettiva" la dico: non capisco perché vi incaponite ad utilizzare distribuzioni di nicchia e meno conosciute, c'è Debian, è lo standard, ha PipeWire, ha Ardour 8.12 nei repository, potete farci girare Reaper, MuseScore 4 sempre aggiornati all'ultima versione scaricando gli eseguibili dai loro siti, ci gira Pianoteq 9, uno sfascio di synth e pure belli, ma di che altro si può avere bisogno?
Però una cosa "soggettiva" la dico: non capisco perché vi incaponite ad utilizzare distribuzioni di nicchia e meno conosciute, c'è Debian, è lo standard, ha PipeWire, ha Ardour 8.12 nei repository, potete farci girare Reaper, MuseScore 4 sempre aggiornati all'ultima versione scaricando gli eseguibili dai loro siti, ci gira Pianoteq 9, uno sfascio di synth e pure belli, ma di che altro si può avere bisogno?
Ad esempio riesco a utilizzare Pianoteq 9 standalone con sistema audio ALSA e frequenza di campionamento a 48 kHz e mi pare 4.0 millisecondi di latenza segnati dal software... E così a memoria non ricordo neanche come ho impostato il buffer, né il valoro effettivo della latenza (comunque <= di 4 ms)... Perché funziona alla perfezione, zero rumori, zero problemi, latenza totalmente impercettibile, tasto e suono sono una sola cosa.
@ d_phatt
Ad esempio riesco a utilizzare Pianoteq 9 standalone con sistema audio ALSA e frequenza di campionamento a 48 kHz e mi pare 4.0 millisecondi di latenza segnati dal software... E così a memoria non ricordo neanche come ho impostato il buffer, né il valoro effettivo della latenza (comunque <= di 4 ms)... Perché funziona alla perfezione, zero rumori, zero problemi, latenza totalmente impercettibile, tasto e suono sono una sola cosa.
Mah, personalmente non ho mai usato distro di nicchia, in questo momento ho due debian (con alsa e jack) e una ubuntu (con pipe-wire).
Ad esempio riesco a utilizzare Pianoteq 9 standalone con sistema audio ALSA e frequenza di campionamento a 48 kHz e mi pare 4.0 millisecondi di latenza segnati dal software... E così a memoria non ricordo neanche come ho impostato il buffer, né il valoro effettivo della latenza (comunque <= di 4 ms)... Perché funziona alla perfezione, zero rumori, zero problemi, latenza totalmente impercettibile, tasto e suono sono una sola cosa.
In ordine sparso
- i kernel RT magari non sono indispensabili oggi (e comunque se uno li vuole sono già belli pronti nei repo), ma una volta ti assicuro che senza non si andava da nessuna parte, bisognava scaricarsi i source del kernel, applicare la patch e ricompilare.
- è vero che in linea teorica ALSA è sufficiente (usando una sola applicazione per volta), ma all'atto pratico senza jack, di nuovo non si va da nessuna parte. Vari software audio senza jack non partono nemmeno, le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
Pipewire sembra semplificare un po' la vita, ma il fatto, appunto, che certe app non lo supportino nativamente e si aspettino di parlare con jack non consente ancora uno scenario ottimale. Poi, è colpa delle app e non di pipewire, ma lato utente la sostanza è quella.
Bob_Braces ha scritto:
i kernel RT magari non sono indispensabili oggi (e comunque se uno li vuole sono già belli pronti nei repo), ma una volta ti assicuro che senza non si andava da nessuna parte, bisognava scaricarsi i source del kernel, applicare la patch e ricompilare.
i kernel RT magari non sono indispensabili oggi (e comunque se uno li vuole sono già belli pronti nei repo), ma una volta ti assicuro che senza non si andava da nessuna parte, bisognava scaricarsi i source del kernel, applicare la patch e ricompilare.
Ci sta, ma negli ultimi 6/7 anni almeno io non ho avuto mai la necessità del kernel RT (io con le DAW e l'audio pro ho sperimentato da Debian 10/11 in poi, prima per quelle cose usavo Windows); utilizzo poco le DAW, ma quando mi è servito è filato tutto liscio, anche con progetti multitraccia relativamente pesanti.
Bob_Braces ha scritto:
all'atto pratico senza jack, di nuovo non si va da nessuna parte. Vari software audio senza jack non partono nemmeno, le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
all'atto pratico senza jack, di nuovo non si va da nessuna parte. Vari software audio senza jack non partono nemmeno, le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
Anche qui, non ho mai rilevato "inutilizzabilità", ma forse sono i miei casi d'uso specifici che non mi hanno fatto riscontrare problemi.
Bob_Braces ha scritto:
Pipewire sembra semplificare un po' la vita, ma il fatto, appunto, che certe app non lo supportino nativamente e si aspettino di parlare con jack non consente ancora uno scenario ottimale. Poi, è colpa delle app e non di pipewire, ma lato utente la sostanza è quella.
Pipewire sembra semplificare un po' la vita, ma il fatto, appunto, che certe app non lo supportino nativamente e si aspettino di parlare con jack non consente ancora uno scenario ottimale. Poi, è colpa delle app e non di pipewire, ma lato utente la sostanza è quella.
Di fatto in realtà una delle idee alla base di PipeWire è di offrire la compatibilità "gratuita" con le applicazioni PulseAudio o JACK (suppongo tramite wrapper), quindi anche quelle "JACK-only" dovrebbero funzionare... Non so a che punto sia sotto questo aspetto, ma essendo di fatto PipeWire il nuovo standard che unisce e sostituisce tutte le soluzioni, ogni applicazione audio attualmente in sviluppo e degna di nota è stata adeguata o deve per forza essere in fase di adeguamento, non c'è altra via per il futuro.
Grazie per il compendio!
Sì devo dire che ero rimasto con la generica impressione che Linux fosse rimasto un po' indietro e invece sono rimasto piacevolmente sorpreso
Ah guarda io ho fatto l'errore di chiedere a un po' di miei amici informatici, mi hanno dato tutti risposte di distro diverse e reagito con scandalo a quelle degli altri Ho scelto CachyOS perchè ho una scheda video nvidia e perchè recentemente è stato consigliato da molte persone per la musica (insieme ad EndeavourOS, sempre basato su Arch). Da relativo neofita (conosco solo Ubuntu che gira sui server dell'università e che uso solo via CLI senza poter ovviamente smanettare) devo dire che per ora mi trovo molto bene, la repository di Arch AUR ha per ora tutto quello che mi serve e l'installazione via riga di comando è molto comoda 
d_phatt ha scritto:
è piuttosto oggettivo lo stato (eccellente) delle cose.
è piuttosto oggettivo lo stato (eccellente) delle cose.
Sì devo dire che ero rimasto con la generica impressione che Linux fosse rimasto un po' indietro e invece sono rimasto piacevolmente sorpreso
d_phatt ha scritto:
non capisco perché vi incaponite ad utilizzare distribuzioni di nicchia e meno conosciute
non capisco perché vi incaponite ad utilizzare distribuzioni di nicchia e meno conosciute
Ah guarda io ho fatto l'errore di chiedere a un po' di miei amici informatici, mi hanno dato tutti risposte di distro diverse e reagito con scandalo a quelle degli altri
Ho scelto CachyOS perchè ho una scheda video nvidia e perchè recentemente è stato consigliato da molte persone per la musica (insieme ad EndeavourOS, sempre basato su Arch). Da relativo neofita (conosco solo Ubuntu che gira sui server dell'università e che uso solo via CLI senza poter ovviamente smanettare) devo dire che per ora mi trovo molto bene, la repository di Arch AUR ha per ora tutto quello che mi serve e l'installazione via riga di comando è molto comoda
d_phatt ha scritto:
ogni applicazione audio attualmente in sviluppo e degna di nota è stata adeguata o deve per forza essere in fase di adeguamento, non c'è altra via per il futuro.
ogni applicazione audio attualmente in sviluppo e degna di nota è stata adeguata o deve per forza essere in fase di adeguamento, non c'è altra via per il futuro.
A quanto ho capito pipewire-jack ha un overhead virtualmente trascurabile rispetto a JACK puro. Farò dopo qualche prova con renoise che se non erro non supporta ancora PipeWire
@ Ko_tatsu
A quanto ho capito pipewire-jack ha un overhead virtualmente trascurabile rispetto a JACK puro. Farò dopo qualche prova con renoise che se non erro non supporta ancora PipeWire
Non conosco il funzionamento di Renoise, però il motivo per cui PipeWire ha preso piede così facilmente e in maniera relativamente indolore è proprio perché garantisce la continuità di funzionamento di tutte le applicazioni basate sui precedenti sound server. Anche se, detto questo, non so se allo stato attuale sia realmente in grado di sostituire integralmente JACK come patchbay audio/MIDI "totale" e low latency inter-app. Magari sì, non lo so, non ho mai avuto bisogno di questa funzionalità. Tra l'altro, se non erro, PipeWire in aggiunta dovrebbe gestire anche i flussi video...
d_phatt ha scritto:
ogni applicazione audio attualmente in sviluppo e degna di nota è stata adeguata o deve per forza essere in fase di adeguamento, non c'è altra via per il futuro.
ogni applicazione audio attualmente in sviluppo e degna di nota è stata adeguata o deve per forza essere in fase di adeguamento, non c'è altra via per il futuro.
A quanto ho capito pipewire-jack ha un overhead virtualmente trascurabile rispetto a JACK puro. Farò dopo qualche prova con renoise che se non erro non supporta ancora PipeWire
@ d_phatt
- Kernel RT: non era davvero necessario per l'audio "pro" su Linux, quello che è davvero importante, anzi fondamentale, è assegnare all'utente i privilegi di real time scheduling, che una volta modificati richiedono un riavvio e nulla più. Inoltre le ultime release di Linux hanno totalmente integrato le caratteristiche real time nella versione standard del kernel (gestendo e superando complessità enormi, questa è gente con gli attributi cubici), quindi non ci sarà più una separazione tra il kernel real time e quello "normale" - quello "normale" potrà funzionare anche in modalità real time.
Se scarico la ultima release di Debian, ho già il kernel RT disponibile?
- Kernel RT: non era davvero necessario per l'audio "pro" su Linux, quello che è davvero importante, anzi fondamentale, è assegnare all'utente i privilegi di real time scheduling, che una volta modificati richiedono un riavvio e nulla più. Inoltre le ultime release di Linux hanno totalmente integrato le caratteristiche real time nella versione standard del kernel (gestendo e superando complessità enormi, questa è gente con gli attributi cubici), quindi non ci sarà più una separazione tra il kernel real time e quello "normale" - quello "normale" potrà funzionare anche in modalità real time.
Pipewire è già configurato per dialogare con il modulo RT del kernel?
Ovidio ha scritto:
Se scarico la ultima release di Debian, ho già il kernel RT disponibile?
Se scarico la ultima release di Debian, ho già il kernel RT disponibile?
Sì, devi cercare linux-image-rt-* nei repo.
Ovidio ha scritto:
Pipewire è già configurato per dialogare con il modulo RT del kernel?
Pipewire è già configurato per dialogare con il modulo RT del kernel?
Come dicevo, su debian non l'ho ancora usato, ma essendo il sistema di default la risposta è sì. Di nuovo, se usi software che non lo supportano, occorre passare da pw-jack che fa da wrapper, funziona bene e non introduce latenze, ma complessivamente riporta almeno parzialmente l'esperienza utente allo scenario con jack.
Bob_Braces ha scritto:
[...] le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
[...] le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
Buongiorno bob, perdonami, ma in che senso Jack si occuperebbe di offrire un buffer "stabile"? Sempre parlando di usare soltanto una applicazione audio alla volta, s'intende, cosa fa Jack più di ALSA? Non sono riuscito a trovare nessuna fonte al riguardo, e ho cercato abbastanza.
Considerando che JACK è comunque basato su ALSA...
@ Ovidio
Se scarico la ultima release di Debian, ho già il kernel RT disponibile?
Pipewire è già configurato per dialogare con il modulo RT del kernel?
Ciao ovidio, come ti ha già risposto @bob_braces la risposta è sì, aggiungo soltanto che Debian 13 Trixie (l'ultima release ufficiale/stabile) è basata sul kernel Linux 6.12, che è la versione in cui sono state integrate e unificate le caratteristiche real time nelle rispettive build, quindi a maggior ragione una volta che hai installato la build RT come ha suggerito bob è tutto già configurato, mutualmente compatibile e pronto per l'uso. (Tra questo e PipeWire, insieme alle eccellenti feature di ALSA e alla buona disponibilità di DAW, plugin e VI, ci rendiamo conto di quanto è migliorata la situazione?)
Se scarico la ultima release di Debian, ho già il kernel RT disponibile?
Pipewire è già configurato per dialogare con il modulo RT del kernel?
Storicamente Debian è sinonimo di "rock solid"... Ma facci sapere come va
@ d_phatt
Buongiorno bob, perdonami, ma in che senso Jack si occuperebbe di offrire un buffer "stabile"? Sempre parlando di usare soltanto una applicazione audio alla volta, s'intende, cosa fa Jack più di ALSA? Non sono riuscito a trovare nessuna fonte al riguardo, e ho cercato abbastanza.
Considerando che JACK è comunque basato su ALSA...
Andare a così basso livello sul funzionamento degli OS non è il mio mestiere.
Bob_Braces ha scritto:
[...] le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
[...] le DAW, che hanno bisogno di un buffer stabile (cosa di cui si occupa jack) sono inutilizzabili.
Buongiorno bob, perdonami, ma in che senso Jack si occuperebbe di offrire un buffer "stabile"? Sempre parlando di usare soltanto una applicazione audio alla volta, s'intende, cosa fa Jack più di ALSA? Non sono riuscito a trovare nessuna fonte al riguardo, e ho cercato abbastanza.
Considerando che JACK è comunque basato su ALSA...
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...)