Miałem dziś możliwość przetestowania PulseAudio w dwóch, dość nietypowych aspektach: poprzez sieć oraz pod Windows XP. Wniosek: to działa :)

Uruchomiłem kilka aplikacji pod Linuksem, a dźwięk wydobywał się ze stojącej obok maszyny Windowsowej (powód był prosty - do maszyny windowsowej były podłączone znacznie lepsze głośniki, a ich przełączenie to by była niezła zabawa). Wszystko działało w miarę bez zarzutu, jedynym problemem było przerywanie dźwięku kiedy maszyna Windowsowa dostawała obciążenie, ale dało się to załatwić zwiększając priorytet procesu PulseAudio na tej maszynie.

Ogólne wrażenie: bardzo pozytywne.

Gdzie DD to 'Domowy Deweloper'. Wiele osób pisze sobie różne rzeczy w domu. Mniejsze większe, nieistotne. Chyba każdy chociaż trochę doświadczony deweloper zna zalety systemów kontroli wersji. Problem w tym, że są one nieco kłopotliwe w użyciu - trzeba konfigurować serwer, dbać żeby działał, był dostępny, itp. Dla osoby niezorientowanej, konfiguracja CVSa czy SVNa może być cokolwiek problematyczna (tak, przyznaję się nie chciało mnie się czytać dokumentacji :P).

Takim właśnie deweloperom, chciałbym polecić ni mniej ni więcej tylko GITa, stworzonego przez Linusa Torvaldsa (znanego nieco szerzej z Linuksa, słyszeliście pewnie ;)), a obecnie rozwijanego przez zespół pod dowództwem Junio C Hamano

Główą zaletą GITa z punktu widzenia DD, jest fakt że nie potrzebuje serwera. Całość infrastruktura kontroli wersji jest utrzymywana bezpośrednio w miejscu gdzie stworzymy nasze repozytorium poleceniem git init.

Jak już utworzyliśmy nasze repozytorium, trzeba dodać do niego pliki. Zrobi to dla nas komenda git add .. Kiedy nasze pliki osiągną zadowalający nasz stan - możemy je 'pchnąć' używając komendy git commit

I to jest zasadniczo wszystko. Jak widać nie musieliśmy nic konfigurować. Po prostu tworzymy repozytorium i z niego korzystamy. Oczywiście to nie wszystko co potrafi GIT. Potrafi on o wiele więcej. Szczególnie polecany jest dla pracy grupowej, wieloosobowej z używaniem wielu gałęzi, łączeniem ich, itp. W końcu, GIT został stworzony na potrzeby jednego z największych projektów open source - jądra Linuxa. Więc jeśli w pracy męczą cię CVSem czy SVNem - zaprzyjaźnij się z GITem. Potem spróbuj przekonać szefa, przedstawiając mu potencjalne korzyści. Jakie? Może lepiej opowiedzą o tym twórcy GITa: tu i tu.

P.S. Taki mały side note: przy okazji poznawania GITa doszedłem do wniosku że dopiero przy tym projekcie objawił się w pełni geniusz inżynierski Linusa. Linux jako taki nie jest aż takim (w kontekście roli którą pełni w nim Linus) wyzwaniem. Po GITcie widać że Linus ma naprawdę bardzo dużo materii szarej :)

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 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ą.

Popełniłem program o nieskromnej nazwie HOI2 Save Saviour. Służy on do naprawiania/poprawiania sejwów gry Hearts of Iron 2. Wszystkich zainteresowanych, zapraszam.

Wielkieś mi uczyniła pustki w domu moim, Moja droga Orszulo, tym zniknieniem swoim! (...)