On Tuesday 14 August 2007, Paul Davis wrote: > On Tue, 2007-08-14 at 11:42 -0700, John Cherry wrote: > > Based on our discussions at the Collaboration Summit (and a slide from > > Donya), I constructed a little diagram to illustrate the Linux audio > > stack. It may not be completely refined yet, but it should give us a > > common way to reference the layers in the Linux audio stack and to > > discuss standardization points in the stack. > > > > https://www.linux-foundation.org/en/Audio_Stack > > from the "too busy to even think dept" .... > > a couple of fixes/refinements... > > the diagram should show FFADO/Freebob (Firewire audio) as a similar > 2-layer entity to OSS. arguably it should show it being dependent on the > kernel ieee1394 drivers too. > > aRts has been declared dead by its founder/chief developers. > > not sure what NMM is, but if its not the same as KDE's "Phonon", you'd > better put Phonon in at the multimedia framework layer. Unless in the
> time since I stopped following it, KDE has declared that dead too and > decided to embrace the G in GStreamer. the NMM backend has indeed been moved into KDE's "playground", which is our place for unbaked code. however, i'm not sure where this "embrace the G in GStreamer" meme keeps coming from because, you see, by that same measure, gstreamer is "as dead" as BOTH the phonon gst backends have also been moved to playground. here's the state of things vis-a-vis gstreamer, phonon and KDE: * gstreamer is an option that has many things going for it * Phonon has two gstreamer backends (!), but they both lag in development; there was some work done to get these started (at least one of the two backends were apparently funded; e.g. "paid for") but it's laid there dormant for quite a bit. i truly hope that the gstreamer development community doesn't miss this opportunity by letting the phonon-gst backend rot in svn and meet the same fate as nmm. * the default Phonon backend at this point is the Xine backend here's the funny thing: this is nearly identical (minus the work-for-hire bit) as the path amarok took. it used to default to gstreamer but eventually just fell back to the simpler xine back end as it worked and had people who worked on it. if there is a real desire, for whatever reason and by whomever, to get gstreamer adopted as a widespread, good-fit solution for it's part of the Linux multimedia stack, then the gstreamer development community really needs to find a way to do simple things like maintain a single backend that will give access to hundreds of apps in one go. the one gst backend is currently 6754LOC and the other is 2,243LOC (both according to sloccount). those are huge numbers. the Phonon API has moved around a bit leading up to the library freeze, but as i understand it the impact to backend code has been rather minimal of late. if we want KDE to embrace any of the letters in gstreamer, then those who have an interest in gstreamer (and/or what it represents) need to get down to coding. i truly hope that happens. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech
pgpgvwdMTGkhq.pgp
Description: PGP signature
_______________________________________________ Desktop_architects mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
