Mentre cercavo di far funzionare il mio suono , mi chiedevo quali fossero i ruoli di ALSA e PulseAudio. Ho installato entrambi e mi chiedevo, ad esempio, chi di loro ha bisogno di sapere sulla mia scheda audio.
Entrambi sembrano essere in grado di usarsi a vicenda, c'è un plug-in pulseaudio per ALSA e sul mio sistema, alsa si presenta come una scheda audio in pulseaudio.
Quale dei due cosa fa, sono alternative o complementari?
Risposte:
ALSA è il mixer audio a livello di kernel, gestisce direttamente la tua scheda audio. ALSA da sola può gestire solo un'applicazione alla volta. Naturalmente, c'è ' dmix ', che è stato scritto per risolvere questo problema. (È un modulo ALSA.)
PulseAudio è un mixer software, in cima all'area utente (come se avessi eseguito un'app). Quando funziona, utilizza Alsa - senza dmix - e gestisce ogni tipo di missaggio, i dispositivi, i dispositivi di rete, tutto da solo.
Nel 2014, è ancora possibile eseguire solo ALSA. Ma a meno che tu non compili le tue applicazioni per te stesso e abiliti il supporto ALSA ovunque - o usi una distribuzione basata su sorgenti come Gentoo - potresti avere problemi di missaggio. Le applicazioni precompilate fornite dalle distribuzioni sono generalmente costruite solo con il supporto di Pulseaudio, non di ALSA puro. Ubuntu, ad esempio, preferisce PulseAudio. Viene fornito con PulseAudio per impostazione predefinita, quindi ogni applicazione viene compilata per utilizzare solo PulseAudio.
PulseAudio ha i suoi vantaggi. La gente dice che è buono per lavorare con l'audio attraverso una rete e risolve alcuni problemi con i flussi audio multicanale che si sono verificati con ALSA puro. È anche presumibilmente più semplice sviluppare app per PA. Per quanto riguarda l'utente finale, è facile selezionare nuovi dispositivi, controllare il volume per app, ecc.
Tuttavia, nella configurazione predefinita aggiunge una quantità non insignificante di latenza nel mix. Questo è un grande svantaggio per alcuni tipi di attività che richiedono bassa latenza come alcuni giochi e software.
OSS è un'alternativa a entrambi, ma non è concesso in licenza ai sensi della GPL, il che rende improbabile che si verifichino molte adozioni da parte delle distribuzioni.
Illustrazione :
tipici sistemi audio basati su PulseAudio, come Ubuntu:
Kernel: ALSA -> Userland: PulseAudio -> app1, app2, app3
Nel tipico sistema Linux, PulseAudio mescola l'audio di tutte le diverse app e le fornisce alla catena di ALSA.
ALSA:
Kernel: ALSA -> dmix -> Userland: app1, app2, app3
Con solo ALSA puro, hai bisogno di dmix per mescolare più app. Senza di essa, ALSA può riprodurre solo un flusso audio da un'app alla volta.
OSS:
Kernel: OSS -> Userland: app1, app2, app3
Con OSS, le app userland parlano direttamente con OSS nel kernel, che mescola i flussi stessi.
Quindi, per riassumere, al giorno d'oggi nel tuo sistema tipico, ALSA parla direttamente con le tue schede audio e Pulseaudio parla con le tue app e programmi e li inserisce in ALSA.
On MAC, Windows, Haiku, GUI runs from the kernel (okay its inside the kernel). Well. It would make sense doesnt it? In realtà no. Ricordi i brutti vecchi tempi di "NT 4 driver video che hanno eliminato il sistema"? Sì, questo è ciò che l'ha causato: eseguire driver scadenti nello spazio del kernel. Perché pensi che Microsoft abbia improvvisamente messo insieme le armi per ottenere i driver firmati in Windows? Bingo! Perché i driver scadenti causavano arresti anomali del sistema. Farli firmare significava farli controllare , e un gran numero di QA fa molta strada ...