| |||||||||||||
Abstraction layers...Abstraction layers...Posted Apr 27, 2006 17:43 UTC (Thu) by cantsin (guest, #4420)Parent article: Phonon: Multimedia in KDE 4 (KDE.News) In other words, KDE 4 applications will talk to Phonon, which in turn will talk to Gstreamer/Xine/[insert media backend here] which in turn will talk either to ALSA/OSS or to a daemon like jack which then talks to ALSA/OSS. Is it justified to be afraid of bloat and a debugging nightmare pending? The article Video I/O on Linux: Lessons Learned from SGI at least does suggest this.
(Log in to post comments)
Abstraction layers... Posted Apr 27, 2006 18:41 UTC (Thu) by jimi (guest, #6655) [Link] I agree that there may be some cause for concern. As a pro audio user, I've been using jack and ardour for a long time. Why doesn't KDE simply code for jack? Adding two more layers doesn't appear to achieve anything. I could understand having Phonon talk directly to jack or ALSA, but GStreamer? If GStreamer provides something wonderful that jack doesn't, why not simply extend GStreamer?
Abstraction layers... Posted Apr 27, 2006 20:17 UTC (Thu) by aleXXX (subscriber, #2742) [Link] When KDE 2 was in the development, the KDE project decided to use arts.To use it directly. KDE 3 still depends on arts. But arts has become unmaintained. Now with KDE4 there's the chance to break binary compatibility. Should KDE decide for gstreamer ? Or for NMM, which seems to be really good in several areas ? Or use Jack directly ? But what if the one which would have been chosen dies in some years ? Then KDE 4 will be left with another dead multimediasystem. The idea of Phonon is to provide a simplified multimedia API for KDE applications. It will hide the details which backend is used, so if now gstreamer seems to be the choice, but in 2 years NMM will have won the race, it won't be a major problem for KDE. KDE applications will be able to work with both backends and not interfere with the rest of the system (as it is the case with arts). Pro-audio applications will still want to use the underlying backend directly, e.g. Jack, because they will require more functionality than Phonon will provide. So, Phonon is an API to ease the development of multimedia-enabled applications. IMO a very sensible decision. Alex
Abstraction layers... Posted Apr 27, 2006 21:13 UTC (Thu) by cloose (subscriber, #5066) [Link] Also the multimedia engine plugins in amaroK clearly show that such an abstraction layer is doable without causing bloat.
Abstraction layers... Posted Apr 28, 2006 14:27 UTC (Fri) by aseigo (guest, #18394) [Link] juk, kaffeine and probably others also follow a similar pattern. it is arather well proven method at this point =)
Abstraction layers... Posted Apr 28, 2006 14:26 UTC (Fri) by aseigo (guest, #18394) [Link] not only is it longevity of the current media frameworks, it's alsoportability and easy of use. with kde2 and kde3, if a system did not have aRts desktop sound was impacted quite harshly. kde4 should work well on many more systems since the OS integrator/vendor can select the media stack they wish to supply and kde can be easily adapted to that by selecting (or writing if it doesn't already exist) the appropriate Phonon backend.
i also expect to see more applications provide multimedia features with
|
|||||||||||||