Linux PipeWire vs Windows ASIO: mistero

  • d_phatt
  • Membro: Guru
  • Risp: 5337
  • Loc: Perugia
  • Thanks: 1153  

21-03-26 19.48

@ 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.

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.