Co bylo v KDE 3 a bude nahrazeno v KDE 4 (diskuse)

[Libor Chocholaty]

Asi se po prechodu na KDE4 pujdu ozrat, abych zmirnil bolest po ztrate stareho dobreho pritele.

[JoHnY]

Doufam ze se nepude nikdo ozrat kvuli aRtsu nebo superkarambe :o]

Dokonce bych tvrdil, ze ta konecna centralizace v KDE4 bude prvni poradnej uklid vsech toolu a API od verze 2. Furt se nam to tu mnozilo a mnozila a mnozilo a... Beee, ja uz chci kwin_composite a KDE4 :) :)

[Marián Kyral]

Ten Phonon tam bude na co? Používám KDE bez aRts a zvuk šlape dobře.

[s0]

to jde na Linuxu. Ale jiné systémy nějaký zvukový server potřebují.

[Mikos]

Ještě jednou - Phonon není zvukový server, je to jen knihovna/framework.

[Mikos]

Phonon není nový aRts! Nejedná se o zvukový server, nýbrž pouze o knihovnu (framework) poskytující programům všechny potřebné multimediální funkce (audio i video). Přičemž Phonon může používat různé backendy, např. GStreamer (ten bude pokud vím defaultní), NMM, atp. Phonon tak budou programy využívat automaticky, nebudete ho nijak spouštět jako třeba aRts.

Díky Phononu nebudou muset vývojáři vázat své programy na nějaký konkrétní multimediální framework (ať už přímo na GStreamer, aRts, libmad, libvorbis, atd.), odpadne spousta duplikace kódu a navíc Phonon vývojářům poskytuje kofortní KDEčkové C++ API (a tak nemusí vývojáři KDE aplikací trnout hrůzou při představě, že by museli např. GStreamer, který je silně GTK + C pozitivní, používat přímo ).

[Zdeněk Štěpánek]

Takze se programy budou vazat na Phonon, taky bezva.....

[Mikos]

Ano, KDE programy se budou vázat na Phonon, na tom není nic špatného Na něco se vázat musí a tohle je IMHO nejlepší možné řešení. Phonon je velice pěkně navržen...

[msk]

+1

[stulda]

+5

[Semo]

Aky je vlastne ucel tychto frameworkov (GStreamer, ....)? Preco nie je vyhodnejsie pouzivat rovno ALSA API? Aspon pokial sa bavime o Linux-only programoch.

[s0]

protoze kde neni linux-only

[Espinosa]

Protoze Phonon ma obsahovat i podporu pro video (jednou treba i pro cichovy vystup :) Doposud se to bastlilo pres ruzne wrapery okolo znamych prehravacu (Xine, Mplayer, GStreamer) a kazdy wrapper mel urcite jine API, jine configuracni GUI (zkuste si treba nastavit kodovani titulku v Kaffeine - je to na 3 mistech! a zabira to ktere podle situace a okolnosti)

Protoze mixovani zvuku v Alse taky neni zadna slast

Protoze alsa jsou kernel drivery ale trend (spravny) je dostat co nejvice veci do userspace, treba to mixovani zvuku

Protoze muze vyjit Alsa api 3.0 a nemusi garantovat zpetnou kompatabilitu (no to Phonon 2.0 nemusi taky, pravda)

Protoze stale hodne programu si s Alsou tak docela dobre neporadi (wine, donedavna Skype)

[Semo]

Naco je prehravacu hudby cinch vystup na video? Napriklad takemu Amaroku. Naopak mpd staci alsa. (To ze sa v nejakom prehravaci idiotsky nastavuje kodovanie titulkov ma malo spolocne so zvukovymi medzivrstvami. V mplayeri sa titulky nastavuju na jednoducho.)

dmix je uz default plugin, takze ho uz nastavovat netreba

Spravnost trendu je vecou nazoru. Ta mixovacia vrstva bude musiet byt vseobecne dostupna pre vsetkych userov simultanne a jej rezia (IMO) bude vacsia rovna alse.

Na toto si si odpovedal sam.

S alsou si neporadi, ale s Phononom ano?

Pre vseobecne osvetlenie: Ja nerypem, ze alsa je najlepsia na svete a vsetko ostatne je na nic. Ja sa do spracovania zvuku prd rozumiem. Ale videl som uz par programov, ktore mali uzasne zavislosti na vsemoznych zvukovych serveroch a frameworkoch a zaroven som videl ine programy, ktore vyuzivaju priamo alsu alebo oss a funkcne su na nerozoznanie od tych prvych. Takze mi unikaju tie uzasne vyhody. Je tu niekto kto s niecim podobnym napriklad programuje, aby by mohol potvrdit aspon vyvojarsku jednoduchost pri pouziti frameworkov?

[Marián Kyral]

Naco je prehravacu hudby cinch vystup na video?

Jó, kdyby tam byla diakritika, tak si nespleteš cinch a čich

[Mikos]

Pokud neexistuje nějaký zvukový framework, tak si každý program musí řešit dekódování všech možných i nemožných audio a video kodeků sám po svém (musí se linkovat na libvorbis, libogg, libmad, ffmpeg, xvid, atd.). Dále si musí po svém řešit všechny možné i nemožné vstupy/výstupy (ještě jednou - ALSA je Linux-only, tzn. chce to minimálně alsu, oss a pokud má fungovat program třeba i na Windows, tak spoustu dalších habaďůr). To je strašná zbytečná duplikace kódu.

Když má člověk po ruce nějaký zvukový framework (třeba GStreamer nebo NMM), tak naopak nepotřebuje řešit miliony různých závislostí a možností. To za něj všechno dělá onen framework, on se linkuje pouze na něj. To je nesmírně praktická věc, která zamezuje duplikaci kódu, ušetří spoustu práce a umožňuje mnohem větší flexibilitu do budoucna. Phonon jde v tomhle ještě dál - poskytuje vývojářům KDE aplikací krásné komfortní C++ API přesně dle KDE zvyklostí a KDE aplikace pak nejsou závislé ani na nějakém konkrétním multimediálním frameworku (GStreamer, NMM, atp.), který může být taktéž platformně závislý nebo se může v budoucnu rozšířit nějaký jiný a lepší (přičemž KDE aplikace pak nemusejí být přepisovány - pouze se přidá podpora pro nový multimediální framework do Phononu).

[Semo]

Dakujem, toto je odpoved vo forme aku som chcel pocut.

Pokud neexistuje nějaký zvukový framework, tak si každý program musí řešit dekódování všech možných i nemožných audio a video kodeků sám po svém

Takze spravne chapem, ze aplikacia vyuzivajuca podobny framework mu len predhodi datovy stream, bez toho aby mu sama nejak rozumela (takze ani nezisti, ci nepredhadzuje nahodne data) a povie co s stym spravit a fw si uz s tym poradi?

[Mikos]

Zhruba tak nějak

[ivan]

Hmm, jen aby tech vrstev nebylo nad sebou prilis mnoho. Linux obecne nema moc dobry nastroje na reportovani chyb, a kdyz nekdo bude prehravat zvuk pres player|photon|gstreamer|libogg|alsa|zvukova karta, tak bude tezky rict proc mu to hraje blbe, neno "nedej boze" proc se mu rozchazi zvuk s obrazem. Pripomelo mi pro problem s padanim Evolution. Z evolutionu rekli, "vime to, ale muze za to libsoap", za libsoap rekli "vime o tom, ale muze za to glib", a za glib rekli, "vime o tom, ale pada to jen v Evolution". Cimz se kruh uzavrel a chyba byla odmitnuta. Sam jsem videl co se deje se systemem, kdyz se zvuk prehrava pres arts, kterej prehrava pres esd - byla to defultni konfigurace. K temhle sound daemonum nemam moc duveru, zatim jsem nezazil, aby to fungovalo stejne dobre jako kdyz se zvuk prehrava skrz oss/alsu primo.

[Mikos]

Tak ještě jednou - aRts byl server, kdežto Phonon je jen knihovna, API. spousta problémů proč aRts fungoval tak strašně jak fungoval se týkala právě toho, že se jednalo o server, jehož návrh byl navíc IMHO dost strašný. Phonon je oproti němu vrchol elegance a takové problémy ani v nejmenším nehrozí.

Nicméně i zvukové servery mají své opodstatnění (pokud jsou dobře navržené) - zeptejte se amatérských/poloprofesionálních hudebníků co pracují na Linuxu, bez Jack serveru se neobejdou.

[miso]

V mplayeri sa titulky nastavuju na jednoducho
v mplayeri sa titulky nastavuju na dvoch miestach, pre mplayer a gmplayer zvlast

[Spike]

ALSA API použiješ pro vytváření složitých multimediální rour pro de/muxování a de/kódování obrazu, zvuku, titulků… nezávisle na platformě? ;)

[Mikos]

ALSA je pouze zvukový výstup, pomocí ALSY nedekóduješ nejrůznější audio a video kodeky Navíc je ALSA dostupná pouze pro Linux a KDE rozhodně není Linux-only...

[Semo]

S tou ALSOU to bol iba priklad, vravim, ze sa toho vyznam iba z uzivatelskeho hladiska. Takze okrem ALSY aj nejake OSS alebo OpenAL (trafil som sa? Je OpenAL alternativou pre OSS a ALSU?).

[Luboš Doležel (Doli)]

OpenAL je multiplatformní API obvykle používané pro 3D zvuk ve hrách. Může používat ALSA nebo OSS.

[Mikos]

Přesně tak, OpenAL je prostě jen další abstrakční vrstva (tedy by se dalo říct tak trochu obdoba třeba toho GStreameru, ale s jiným určením). OpenAL je tak trochu analogie OpenGL pro 3D zvuk. Dokonce v rámci projektu OpenAL existuje i ALUT - analogie GLUT pro OpenGL.