Kiedy tylko pojawiają się informacje na temat PulseAudio, od razu podnoszą się głosy "Ale po co", "Ale jest przecież OSS", "Ale jest przecież ALSA", "Ale jest przecież Gstreamer", itd. itp. Osoby które tak mówią, nie rozumieją niestety jak powinno przebiegać (i czasami przebiega) przetwarzanie dźwięku w nowoczesnych systemach operacyjnych.

Ponieważ jeden obraz mówi więcej niż tysiąc słów, a ja jestem leniwy, zacznijmy od prostego schematu:

Obrazek

Obrazek ten przedstawia chyba najlepszy sposób przepływu informacji. To czego w nim brakuje, to sprzętu po stronie lewej i użytkownika po stronie prawej. Jeśli zrozumiemy o co w nim chodzi, to już (mam nadzieję) nie będzie w przyszłości głupich (nielogicznych) pytań. No to lecimy. Od prawej.

Nasz Zwykły Użytkownik (ZU) klika sobie w swojej ulubionej aplikacji na przycisk PLAY, aby odtworzyć swoją ulubioną, w pełni legalną, empetrójkę. Aplikacja, komunikuje się biblioteką multimedialną, i w największym uproszczeniu mówi: odtwórz TĄ empetrójkę.

Warstwa multimedialna bierze empetrójkę i dekoduje ją, tzn, przetwarza skompresowaną postać na postać nieskompresowaną. Postać nieskompresowana jest następnie przesyłana o serwera dźwięku.

Serwer dźwięku bierze to co dostał, i robi z tym kilka rzeczy. Jeżeli sprzęt nie obsługuje formatu dźwięku w którym został on dostarczony, przekształca go na format obsługiwany przez sprzęt. Dodatkowo, jeżeli sprzęt nie potrafi samodzielnie miksować kilku źródeł, robi to właśnie serwer dźwięku. Do tego, serwer dźwięku może dodać jakieś efekty specjalne takie jak zmianę głośności, echo, pogłosy, cokolwiek się użytkownikowi spodoba. Następnie przekazuje to do warstwy sterowników.

Warstwa sterowników bierze to co dostała i po prostu przesyła to do sprzętu. Jej jedynym zadaniem powinno być przedstawienie możliwości sprzętu w sposób jednoznaczny dla serwera dźwięku.

Oczywiście, to jest uproszczony schemat. Wiele aplikacji (np. gry) może opuścić warstwę multimedialną, bo czasami jej wykorzystanie nie ma sensu.

Dlaczego tak?

Bo tak :). Ale poważniej. Taka architektura daje nam wiele korzyści i może być naprawdę szybka. Nie jest to jedyna tego typu architektura, w sieciach jest podobnie. Faktyczny model TCP/IP to bodaj pięć warstw (albo cztery, nie pamiętam dokładnie), a idealny model teoretyczny ISO-OSI zakłada do siedmiu. I to działa, do tego całkiem szybko.

W wypadku dźwięku, główną zaletą jest separacja. Programista aplikacji czy bibliotek, nie musi się martwić o możliwości sprzętu. Przez co nie musi zapewniać u siebie dla przykładu konwersji pomiędzy różnymi formatami dźwięku (a mogą być różne częstotliwości, zapis ze znakiem i bez znaku, skala logarytmiczna lub liniowa...) którą bardzo łatwo zrobić... ŹLE. Przykładem jak tego nie robić jest alsowy dmix :).

W tym modelu, prawie cały ciężar zrobienia łatwych (no, niekoniecznie ;)) rzeczy dobrze spada na serwer dźwięku. Jedno miejsce. Cała ta separacja daje też dodatkowe korzyści. PulseAudio w założeniu jest wielosystemowe, tak więc programista używając go zapewnia swojemu programowi przenośność pomiędzy systemami/platformami za darmo.

Jak widać mamy sporo potencjalnych korzyści. Oczywiście, są też zagrożenia. Podstawowym zagrożeniem jest fakt, że jeżeli serwer dźwięku będzie kiepsko napisany, to całość zacznie się sypać. Tak jest dla przykładu z Esound, który może był dobry kiedyś, ale na dzień dzisiejszy nie nadaje się już prawie do niczego. Patrząc jednak na developerów PulseAudio, widać że znają się na rzeczy i co najważniejsze: potrafią przyznać się do błędu.

Tak więc, proszę już nie pytać "ale OSS, ALSA, (whatever)". Tak ma być, a wymyślili to ludzie którzy naprawdę wiedzą co robią.