Z dźwiękiem w Linuksie nie jest specjalnie dobrze. Nie chodzi mi o obsługę sprzętu - to co możemy dostać w sklepie jest zazwyczaj obsługiwane (schody zaczynają się przy niektórych bardziej profesjonalnych rozwiązaniach). Burdel panuje niestety od strony oprogramowania.
Od strony jądra mamy dwa podsystemy: ALSA i OSS. OSS jest rozwiązaniem w miarę uniwersalnym (w świecie Unixowym), lecz Linuksie jest przestarzały. ALSA zaś jest rozwiązaniem czysto Linuksowym. Oprócz tego mamy różne soundservery: Esd, aRts, Jack, NAS. Jakby tego było mało mamy kilka różnych bibliotek programistycznych do tego wszystkiego. Wszystkie systemy są ze sobą w różny sposób powiązane. Mamy kilka niezależnych frameworków multimedialnych (Gstreamer, Xine, Mplayer, Phonon). Żadne z tych rozwiązań nie nadaje się do wszystkich zastosowań, żadne nie daje użytkownikom dokładnie tego co chcą, mają różne funkcjonalności. No ale, przede wszystkim: o co w tym wszystkim chodzi?
Najniższą warstwą tego bałaganu jest podsystem jądra. Zapewnia on podstawowy dostęp do urządzeń dźwiękowych podłączonych do naszego komputera.
Następnie mamy serwer dźwięku. Serwer dźwięku pośredniczy pomiędzy aplikacjami a warstwą jądra. Zapewnia on różnorodną funkcjonalność (o tym dalej), a najważniejszą z nich jest miksowanie kanałów: jeśli nasz sprzęt (tzn. chipset muzyczny) nie umożliwia równoczesnego odtwarzania dźwięków z kilku źródeł, to właśnie zadanie spada na serwer dźwięku.
Nad tym mamy wspólna warstwę bibliotek, frameworków i aplikacji. Wspólną z punktu widzenia tej notki, dlatego nie będę się nią więcej zajmował.
O wadach podsystemów jądra (ALSA i OSS) już pisałem. Teraz coś o serwerach dźwięku.
ESD (Enlightened Sound Daemon) to chyba najstarsza część, obecnie, jak sugeruje nazwa ;) jest rozwijany przez projekt Gnome. Rozwijany to może za duże słowo. ESD jako taki ma palmę pierwszeństwa, a główną jego zasługą jest pokazanie jak serwer dźwięku pracować nie powinien. Głównym powodem powstania ESD było odgrywanie dźwięków interfejsu użytkownika. To zadanie wykonuje nawet nieźle, lecz zupełnie nie nadaje się i nie radzi sobie z dźwiękiem który ma być odtwarzany w czasie rzeczywistym, z niskimi opóźnieniami. Multimedia jeszcze sobie dają z nim radę, lecz gry czy VoIP już nie. Tak więc ESD raczej zwija się, niż rozwija.
aRts to serwer stworzony na potrzeby projektu KDE. Od lat nie rozwijany, porzucony i zarzucony. Wymieniłem go tylko z obowiązku wbicia szpili miłośnikom KDE: tak im też się niektóre rzeczy nie udają ;)
Jack to całkiem dobry serwer. Niestety jest przeznaczony głównie dla profesjonalistów (tzn. nie informatyków profesjonalistów, ale osoby zajmujące się dźwiękiem profesjonalnie). W związku z tym czasami zachowuje się on "dziwnie" z punktu widzenia zwykłych użytkowników, a jego konfiguracją można straszyć już nawet wyrośniętych przyszczersów ;) Tym nie mniej jest to dobry produkt - ale nie na desktop.
NAS to serwer sieciowy. Tzn, uruchamiamy odtwarzacz na jednej maszynie, słuchamy na drugiej. Tą funkcję wypełnia całkiem dobrze, ale niewiele ponadto.
Dla obowiązku wspomnę tu jeszcze o ALSA, która posiada pewne elementy serwera dźwięku - lecz jest przeznaczona tylko dla Linuksa, co ją niestety dyskwalifikuje w roli uniwersalnego rozwiązania.
Zakładam że inteligentni czytelnicy domyślają się, że mam zamiar omówić to coś nowego, co ma być remedium na te problemy. I owszem :)
PulseAudio to nowy, dynamicznie rozwijający się serwer dźwięku, który trafi do następnego wydania Ubuntu (tak Livio, wiem że w Fedorze już jest ;)). Twórcy Pulse, wyciągnęli wnioski z błędów popełnionych przez starsze projekty, i postanowili rozwiązać problem raz a dobrze.
Na początek zaznaczę tylko że Pulse jest ciągle we wczesnej fazie. Większość rzeczy już działa, niektóre jeszcze nie, no i to tu to tam znajdzie się jakiś błąd.
Najważniejsza w PulseAudio jest szybkość. Ludzkie odbieranie dźwięku ma to do siebie, że (np. w przeciwieństwie do video) nie toleruje opóźnień czy przerw. Dlatego wszędzie gdzie można, Pulse stara się minimalizować opóźnienie (latency) dźwięku, czyli czas od kiedy aplikacja wydaje komendę 'graj' do momentu kiedy słyszymy dźwięk w głośnikach.
Drugą najważniejszą rzeczą jest konfiguracja, a raczej jej brak. Pulse ma po prostu działać, mimo naprawdę potężnych możliwości. W bardzo prosty sposób, od razu możemy użyć głośników na USB które przed momentem podłączyliśmy. Bezproblemowo możemy połączyć dwie karty muzyczne w jedną. Możemy przesłać nasz dźwięk przez sieć do głośników innego komputera. Wszystko kilkoma kliknięciami myszki. O takich rzeczach jak automatycznie ściszanie odtwarzaczy muzycznych w chwili gdy dzwoni VoIP, zapamiętywania ustawień każdej aplikacji, regulacji głośności per aplikację czy też wsparcia dla blutootcha już nawet nie wspomnę ;)
Trzecią cechą jest kompatybilność. Pulse za założenia ma działać na wszystkim, a wszystko ma działać na Pulse. Tak więc nie ważne czy Windows, czy FreeBSD czy Linux czy Solaris, Pulse ma na tym zadziałać. Nieważne czy aplikacja ma obsługę ALSA, OSS czy Jacka, czy NAS, czy ESD, czy też natywnie PulseAudio, ma działać.
Wszystko to ładnie brzmi prawda? Fakty jednak świadczą na korzyść PulseAudio. Jak już napisałem - rozwija się bardzo dynamicznie i na dzień dzisiejszy developerzy Pulse deklarują że 95% istniejącego, Unixowego oprogramowania zadziała ich serwerem. Myślę że są nazbyt skromni ;). Ze swojego doświadczenia mogę powiedzieć że z PulseAudio działa praktycznie wszystko, a problemy sprawiają tylko naprawdę bardzo egzotyczne, jednostkowe wypadki. Zaś co do odwiecznego problemu latency mogę powiedzieć że dokonano tu naprawdę dobrej roboty :)
No, a jak ktoś się zapyta: po co to wszystko? To ja odpowiem: głupie pytanie ;) Proponuję wypróbować, bo PulseAudio niewątpliwie pojawi się niedługo w dystrybucji której używasz. Może nawet już jest :)
