[Desktop_architects] Linux Audio Stack
Aaron J. Seigo
aseigo at kde.org
Tue Aug 14 16:16:26 PDT 2007
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
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20070814/1a2685b3/attachment.pgp
More information about the Desktop_architects