lacirtaMert az EsounD, ami előtte volt a GNOME hangszervere, már túlhízott és körülményes, nem volt értelme tovább vonszolni. Ráadásul addig tényleg több hangrendszer futott szimultán egymással, mert van aminek OSS, van aminek ALSA, van aminek meg már ESD kellett. Erre jött a korábbi nevén nagyon ötletes Polypaudio, ami az egyes hangrendszerek folyamataira rátapadt a különféle API-kkal, mint egy polip a karjaival. Beékelődik oda, ahol a szimultán hangrendszerek futása miatt nem működhettek együtt azok, és szépen elosztogatja a folyamatokat az események alapján, hogy mi történik.
Ugyanilyen DE-szintű hangelosztó rendszer van a KDE-ben is, ott Phonon a neve, természetesen máshogy működik. Persze "jogos" lenne a kérdés, hogy akkor miért kell külön a kettőnek, miért nem használnak egységeset.
Az igazság az, hogy eddig se így volt. A KDE egy szintén nagyon körülményes hangszervert, az arTs-ot használta a 3.x-es szériában, és ott is úgy működött, hogy az egyes alkalmazások a saját kényük-kedvük szerint használták, vagyis többnyire nem használták, és egyenként hívogatták meg az OSS, ALSA és egyéb kéréseiket.
A Phonon is ebbe ékelődött be.
Még mindkettőn van mit fejleszteni, de ha mindenki csak legyalulja, akkor egyre kisebb az esélye, hogy egy-egy hibát javítanak, vagy észrevételt implementálnak.
Megjegyzem a KDE ebben a tekintetben "interfésznácibb", mint a GNOME. Ott Phonon nélkül tudtommal gyakorlatilag használhatatlan a rendszer.
Fontos még megemlíteni a GStreamert is, ami jelenleg még mindig egy fapados hangszerver üzemmódot is ellát, hiszen a Multimédiarendszer-választó az egy GStreamer adminisztrációs felület. Ott beállíthatod, hogy a GStreamert használó alkalmazások (pl. Rhythmbox, Totem, Hangrögzítő, stb.) merre kommunikáljanak. De a GStreamert nem erre tervezték. A GStreamer feladata csak és kizárólag a kodekek kezelése, és lepasszolása az alapértelmezett hangrendszernek. Ő nem tudja eseményalapon elosztani, hogy az most ALSA, OSS, ESD, vagy PA. Ezért kellett oda a PA. Ha a GStreamer csak a PA felé kommunikál, akkor már maga a GStreamer kevesebb erőforrást eszik. Épp elég neki a kódolás/dekódolás.
Ami meg nem a GStreamerrel dolgozott, az közvetlenül nyúlkált a hengendszerek (OSS, ALSA, ESD) felé. Lásd fentebb.
Hasonló megy Kubuntun a Phononnál is. Ott tudtommal az alapértelmezett dekóder a GStreamer (hiába GNOME-közeli). Bár ott mintha kicsit más lenne a helyzet, lévén például az Amarok a Phononra csatlakozik, a Phonon csinál egy GStreamer hurkot, és a dekódolt streamet a Phonon dobja tovább a kernel-szintű hangrendszerre, ami esetünkben az ALSA.
A Rhythmbox viszont úgy működik, hogy a GStreamerre csatlakozik, ami dekódol, a streamet átdobja a PulseAudionak, és az átpasszolja a kernel-szintű hangrendszernek, ami esetünkben ismét az ALSA.
A Xine, az mplayer és a VLC működése már más tészta. Őket nem ismerem. :)
Ehhez képest a még régebbi médialejátszók működése tényleg érdekes. Ott a médialejátszóba volt beleépítve (vagy pluginnel beletéve), hogy melyik formátumhoz melyik dekódert használja (gyakran nem is csak a libet, hanem a teljes binárist is), és maga a médialejátszó csatlakozott közvetelnül a kernel-szintű hangrendszerhez. Így ha több médialejátszó alkalmazás is futott, akkor azok nem tudtak tisztességesen szimultán működni, mert semmi sem osztotta el őket. Ha jól sejtem.
És még valami: a kulcsszó a modularitás. Az utóbbi időben egyre több alapvető rendszerelem ebbe az irányba megy, mert könnyebb egy moduláris szoftvert karbantartani és fejleszteni, mint egy monolitikus monstrumot.
UI: Készült egy ilyen okosság a PulseAudio kezeléséhez. Na ilyet csak a PA tud, ha GNOME-ról van szó:
http://www.ubuntugeek.com/ear-candy-a-nice-pulseaudio-volume-manager.html
