[Desktop_architects] Linux Audio Stack
Aaron J. Seigo
aseigo at kde.org
Tue Aug 14 20:47:32 PDT 2007
On Tuesday 14 August 2007, Paul Davis wrote:
> On Tue, 2007-08-14 at 17:16 -0600, Aaron J. Seigo wrote:
> > 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,
> and what do you suppose that part of the stack is? my perspective
i'm probably the wrong person to ask that question of. which is why i worded
it as i did above =) and it's not because i don't have an opinion or even
some understanding to offer, but rather because i think it's more useful to
represent the needs that follow from the POV of those who deal with the
desktop apps themselves.
so: i care about the desktop layer. and just as i care about X only inasmuch
as i have to (thankfully only very) occasionally deal with its APIs directly
in my code and that it's quality and capabilities enable (or don't) desktop
apps, i don't care much about gstreamer or nmm or $MEDIA_SYSTEM other than
the interface to the desktop layer that is provided and how they enable (or
don't) desktop apps.
as such, if gstreamer is where the Free software community wants to head, then
getting gstreamer support in Phonon is a pretty basic requirement in that
direction from my perspective.
someone said that KDE had essentially adopted gstreamer, which is patently
false. that's when i piped up to set the record straight so that in there
aren't nasty surprises in the future because people assume something that
isn't happening is happening.
so from where i stand it hardly matters where $MEDIA_SYSTEM fits into the
stack or how good it is; if it doesn't have a Phonon backend it's essentially
cut off from a huge number of free software apps including the ones i spend
my life working on and with. thankfully a Phonon backend can be written at
any point in time, but it still needs to be written and maintained.
the gstreamer backend is much of the way there, it just needs completion.
> i don't believe that GStreamer is suitable as a general purpose API for
> all apps. its too complex and offers way too many capabilities for most
> of them.
agreed. and since this is hardly unique to gstreamer, it was one of the
primary reasons for Phonon (see more on this below)
> Community) that seems even close to viable for "stringing together all
> kinds of media processors within an application and ultimately making
> their data stream go somewhere useful".
if this is true, then it behooves us (the Free software community) to ensure
that there is support for it far and wide. KDE developers have made a rather
large investment in making it possible to hook into $MEDIA_SYSTEM. we're
really not into playing the "pick the media framework" game, doubly so now
that we're native on Windows and MacOS as well. more important to our app
developers is "make it work with whiever media framework is there". in the
case of gstreamer, the "last mile" is a maintained gstreamer backend for
that doesn't exist.
that is a shame.
how do we fix it?
and no, i don't think expecting the KDE multimedia developers to write a
Phonon backend for every media system out there makes any sense. what makes
sense (to me, anyways) is people putting their code with their mouth is when
it comes to claiming "we have a great media system, you should use it". with
phonon it's possible to write a layer once and get access to a huge number of
apps with that effort.
> > 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.
> not sure what this means. GStreamer itself has several backends that
> talk to different I/O systems (ALSA, JACK, disk files and more). so i
> don't know what you mean by "maintain a single backend". another layer
> on top of GStreamer that works for lots of different apps?
yes, that would be Phonon (i figured the context of my email would have made
that clear =).
from KDE 4.0 on virtually -all- multimedia in KDE (and it appears likely many
Qt apps) will go through Phonon. Phonon has two really nice features:
- dead simple API that is consistent in design with other desktop APIs found
- multiple backends
the ramifications are:
- the multimedia features that 95%+ of desktop apps need (e.g. anything less
media demanding than pro audio tools) presented in a way that 95%+ of desktop
developers can quickly make things work
- allows app developers to concentrate on their app's features, not the
intracacies of media management, recording and playback
- cross platform (e.g. we'll be able to use "native" windows and mac media
facilities on those platforms, and whatever system is available on a given
linux/bsd/unix provided there is a back end for it)
- future proof (even if the underlying backends shift around, e.g. the Next
Great Thing In Free Software Media comes along in the future, app code won't
need to be touched)
- cooperative: KDE can easily adapt to other audio systems by instantiating
different backends so that other systems which are less flexible and
therefore require a given lower level media framework can be worked with
(e.g. avoid the aRts vs esd vs gstreamer vs .. madness of the past)
KDE apps are moving (and in many cases, have already moved) to using Phonon
for the above reasons. if gstreamer, nmm, etc want to be a part of this
party, then the backends for them need to be written and maintained. if they
don't care about that ecosystem, then they don't need to. i think that would
be a fundamental mistake, however.
i do think it's a rather nice way to figure out which media framework
community is truly dedicated to being a broadly relevant system and has the
resources needed to be a long term player. hopefully several groups show up
and then the user base, system integrators and OSVs (aka "the market") can
pick the winner(s) darwin style.
right now, on the basis of "code having been written and working", the winning
system is xine. it works for what the vast majority of desktop apps need, is
reliable and pervasive. i bet other systems could do better. from the "monty
python" perspective, i think it's pretty funny that the xine backend is so
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/10d8f577/attachment-0001.pgp
More information about the Desktop_architects