[Desktop_architects] Linux Audio Stack

Paul Davis paul at linuxaudiosystems.com
Tue Aug 14 17:38:55 PDT 2007


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
suggests that GStreamer is not an API for simple desktop/office
productivity/consumer media apps. rather, its a rather complex system to
allow fairly complex media apps to be built, in ways that as far as i
know, no other API that we have to hand can do. its more than a little
ugly when you want to do something complex, but i've been impressed from
my own little excursion into PyGST how simple it is to do simple stuff
with GStreamer. the "playbin" element is a fairly remarkable creation.

they key point is that GStreamer isn't a backend either ... it itself
has lots of other backends. So, it you need the kinds of capabilities
that GStreamer offers, I am not sure where else you can turn to. If you
don't need them, then a system like PulseAudio, which only aims to wrap
I/O capabilities and not provide sophisticated media handling, would
make a lot more sense. From what I saw of Phonon the last time I looked,
it appeared to be more on the level of PulseAudio than GStreamer. I
could be very wrong about that.

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. but i do know that its development team have struggled long and
hard to design a system that does things no other system can do. one
might argue that their solution is wrong, or weak, or inefficient or
whatever, but I don't see another system out there (sorry Helix
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".

>  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?

--p



More information about the Desktop_architects mailing list