Enquanto tentava fazer meu som funcionar , fiquei pensando nos papéis da ALSA e da PulseAudio. Eu instalei e fiquei pensando, por exemplo, qual deles precisa saber sobre minha placa de som.
Ambos parecem capazes de usar um ao outro, há um plug-in pulseaudio para o ALSA e, no meu sistema, o alsa aparece como uma placa de som no pulseaudio.
Qual dos dois faz o quê, são alternativas ou complementares?
Respostas:
ALSA é o mixer de som no nível do kernel, gerencia sua placa de som diretamente. O ALSA por si só pode lidar com um aplicativo por vez. Obviamente, existe o ' dmix ', que foi escrito para resolver esse problema. (É um módulo ALSA.)
PulseAudio é um misturador de software, no topo da área do usuário (como se você estivesse executando um aplicativo). Quando roda, usa o Alsa - sem o dmix - e gerencia todo tipo de mixagem, os dispositivos, os dispositivos de rede, tudo por si só.
Em 2014, você ainda pode executar apenas o ALSA. Mas, a menos que você compile seus aplicativos e habilite o suporte ALSA em qualquer lugar - ou use uma distribuição baseada em fonte como o Gentoo -, você poderá ter problemas de mixagem. Aplicativos pré-compilados e distribuídos geralmente são criados apenas com suporte ao Pulseaudio, não ao ALSA puro. O Ubuntu, por exemplo, prefere o PulseAudio. Ele vem com o PulseAudio por padrão, portanto, todos os aplicativos são compilados para usar apenas o PulseAudio.
PulseAudio tem seus benefícios. As pessoas dizem que é bom para trabalhar com áudio em uma rede e resolve alguns problemas com fluxos de áudio multicanal que aconteciam sob o ALSA puro. Também é supostamente mais fácil desenvolver aplicativos para PA. No lado do usuário final, é fácil selecionar novos dispositivos, controlar o volume por aplicativo etc.
No entanto, na configuração padrão, ele adiciona uma quantidade não insignificante de latência ao mix. Este é um grande golpe para certos tipos de tarefas que exigem baixa latência, como alguns jogos e software.
O OSS é uma alternativa para ambos, mas não está licenciado sob a GPL, o que dificulta a adoção de muitas distribuições.
Ilustração :
Sistemas de som típicos alimentados por PulseAudio, como Ubuntu:
Kernel: ALSA -> Usuário: PulseAudio -> app1, app2, app3
No sistema Linux típico, o PulseAudio mistura áudio de todos os seus aplicativos diferentes e os alimenta com a ALSA.
ALSA:
Kernel: ALSA -> dmix -> Usuário: app1, app2, app3
Com o ALSA puro, você precisa do dmix para misturar vários aplicativos. Sem ele, o ALSA só pode reproduzir um fluxo de áudio de um aplicativo por vez.
OSS:
Kernel: OSS -> Userland: app1, app2, app3
Com o OSS, os aplicativos da userland conversam diretamente com o OSS no kernel, que mistura os fluxos em si.
Para resumir, em seu sistema típico atualmente, o ALSA conversa diretamente com suas placas de som, e o Pulseaudio conversa com seus aplicativos e programas e os alimenta no ALSA.
On MAC, Windows, Haiku, GUI runs from the kernel (okay its inside the kernel). Well. It would make sense doesnt it? Na verdade não. Lembra dos velhos tempos ruins dos "drivers de vídeo do NT 4 que destruíram o sistema"? Sim, foi o que causou isso - rodar drivers ruins no espaço do kernel. Por que você acha que a Microsoft subitamente se empenhou em obter drivers assinados no Windows? Bingo! Porque drivers ruins estavam causando falhas no sistema. Trazê-los assinado significava fazê-los controlados , e uma smidgeon de QA vai um longo caminho ...