Os sistemas de áudio são um velho problema no Linux. O primeiro conjunto de drivers de áudio para a plataforma foi o conjunto OSS (Open Sound System), que apesar do nome, era na verdade uma suíte comercial, cujos desenvolvedores ofereciam uma versão open-source (com algumas limitações sobre a versão comercial) que era incluída no Kernel.
O OSS era um sistema simples e que funcionava bem, mas com o tempo o desenvolvimento desacelerou e ele começou a se tornar cada vez mais defasado, com mais e mais modelos de placas de som ficando sem suporte ou sendo suportadas de forma limitada.
Surgiu então o Alsa, que trouxe uma interface muito mais complexa, porém mais elaborada. O projeto conseguiu atrair um bom volume de desenvolvedores e acabou se tornando o sistema de áudio default, substituindo o OSS. O Alsa inclui também um sistema de compatibilidade com o sistema antigo, que permite que aplicativos antigos, com suporte apenas ao OSS, continuem funcionando.
No modelo tradicional, os aplicativos que usam o som enviam o fluxo de áudio diretamente ao driver de som (que por sua vez faz parte do Alsa ou do OSS) que, por sua vez, se encarrega de fazer as operações necessárias e o enviá-lo à placa de som. O grande problema é que a maioria dos chipsets de som atuais (que, assim como os softmodems, regrediram em relação a placas offboard como as SB Live, usadas a uma década atrás, passando a executar cada vez mais funções via software) não suportam a reprodução de mais de um fluxo de áudio simultaneamente, de forma que quando a placa é acessada diretamente, você não consegue usar dois aplicativos que usam o som (o Amarok e o Skype, por exemplo) simultaneamente.
Surgiram então os “servidores de som”, que atuam como intermediários entre a placa de som e os aplicativos, combinando diversos fluxos de áudio (de forma que vários aplicativos possam usar o som simultaneamente) e executando outras funções. Eles podem ser usados também para adicionar funções extras, como a possibilidade de usar som através da rede (um recurso usado por aplicativos de acesso remoto ou sistemas de terminais leves, como no caso do LTSP).
O grande problema com os servidores de som no Linux é que existem diversas opções e nenhum é usado por todos os aplicativos, dando origem a diversos tipos de problemas, um exemplo de falta de padronização que atrapalha a evolução do sistema.
Um dos exemplos mais conhecidos é o Arts, o servidor de som do KDE 3. Ele é usado ao marcar a opção “Habilitar o sistema de som” dentro do Kcontrol:
Embora tenha sido usado durante toda a fase 3.x do KDE, o Arts possuía diversas deficiências e acabou sendo descontinuado em 2004, o que levou os desenvolvedores do KDE a adotarem outro servidor de som, o Phonon, a partir do KDE 4.
Do lado do Gnome, o servidor mais tradicional é o ESD, usado desde as primeiras versões do desktop. Assim como o Arts, o ESD possui diversas limitações, o que levou ao aparecimento do PulseAudio, que passou a ser o servidor de som usado por padrão no Mandriva (a partir do 2008.1), no Ubuntu (a partir do 8.04) e também no Fedora, a partir da versão 8.
O PulseAudio inclui diversos recursos avançados, incluindo controles de volume independentes para cada aplicativo, o que abre as portas para algumas funções interessantes. Um programa de VoIP como o Skype poderia ser configurado para baixar automaticamente o volume do MP3 tocando no player de áudio quando você recebesse uma chamada, por exemplo.
Ele possui também uma boa arquitetura de streaming de áudio via rede, que se bem usada pelos aplicativos, pode dar origem a recursos interessantes. Um player de áudio rodando no seu notebook poderia ser configurado para usar as caixas de som do seu PC principal quando você estivesse dentro da área de cobertura da rede wireless (ou, seja, quando estivesse em casa), em vez de usar as caixinhas do próprio notebook, por exemplo.
Você pode encontrar dicas de como configurar diversos aplicativos para trabalhar em conjunto com o PulseAudio no: https://pulseaudio.org/wiki/PerfectSetup
O grande problema é que o PulseAudio sofre do mesmo problema que todos os outros servidores de áudio no Linux, que é o fato de nem todos os aplicativos estarem preparados para lidar com ele. As primeiras versões possuíam também alguns problemas de performance e de estabilidade, o que fez com que muitos ficassem com uma imagem negativa do novo sistema, depois de ter problemas relacionado a ele no Ubuntu 8.04 ou no Fedora 9, por exemplo.
Apesar dos pesares, o PulseAudio veio para ficar, o que, depois de resolvidos os problemas de transição, pode ser uma boa coisa, já que ele pode marcar, finalmente, o surgimento de um servidor de som padrão para o Linux, que seja adotado por todas (ou pelo menos quase todas) as distribuições e possa ser usado por todos (ou quase todos… 🙂 os aplicativos.
O Phonon (do KDE 4.2), por exemplo, utiliza o PulseAudio como backend quando disponível, assim como o GStreamer, que é utilizado pelos aplicativos do Gnome, um raro caso de consenso entre os desenvolvedores dos dois ambientes.
Apesar disso, nenhuma solução é livre de problemas. Uma solução temporária, para casos em que o PulseAudio trava a placa de som, impedindo que outros aplicativos a utilizem é simplesmente matar o processo, usando o:
# pulseaudio -k
… ou, se você quiser ser mais enfático, usando o “killall pulseaudio”.
Em muitos aplicativos, o default é utilizar o Arts ou o ESD sempre que possível, mas caso você esteja tendo problemas com o som em algum aplicativo em particular, experimente dar uma olhada na configuração e ver se não existe uma opção para mudar o servidor de som usado, passando a utilizar o PulseAudio:
Esta postagem foi modificada pela última vez em 21/03/2011 19:46