[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 
phonon.

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 
around KDE
- 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 
far ahead.

-- 
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
Type: application/pgp-signature
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 mailing list