[gst-devel] I want to do an audio app

[Thomas Vander Stichele]

> Hey all, just joined the list.
Hey Tim,

Thanks for providing some feedback, it's always good for us to hear what 
"newcomers" think about GStreamer, and if we've improved or not.

> I've been working for a few weeks, and thinking for a few months, on an
> audio application.  Specifically, something akin to FruityLoops under
> windows.  Something that integrates sound creation, effects, outpit and
> parameter control.

Sounds like fun ;)

> As I was banging out a plugin API, I was pointed at GStreamer.  Now, it
> seems that a LOT of work has gone into GStreamer and the goals are FAR
> loftier than my own.  However, it is horribly complicated.  I guess that is
> the price you pay for total flexibility.

It is complicated to get into.  The manual helps a lot in explaining the 
concepts however, and in the end the complexity is worth it.

> I'm not sure yet that GSTreamer meets all my needs, and I just can't seem to
> get gst-editor to do ANYTHING but dump core.

Really ? gst-editor should work, there has been a lot of work on it 
recently and it's a lot harder to crash these days ;) If you provide us 
some feedback (preferably in bugzilla.gnome.org), with versions of the 
various components and if possible a traceback, or a pipeline save file, 
and output of gst-feedback attached to it, we can fix this for you .

> Here are my thoughts after playing with and reading on GStreamer for a few
> days.  I'd love for people to address them, point out where I am wrong, or
> where docs are wrong, etc.
> 
> 1) It takes too much effort to write a plugin.  One has to learn all the
> GLib, GObject and GStreamer APIs.  It has taken me days to figure out what
> is going on in the examples, and they are very simple.

Writing plug-ins is not easy.  We are going to rewrite the Plug-in 
Writer's Guide, but if you're new to GStreamer you really shouldn't start 
by writing a plug-in.  Personally, after getting used to them, I really 
like all of the G API's, but they're a special flavour to acquire I guess 
if you're used to standard C.
Also, not all plug-ins are of equal quality.  Good plug-ins to look at for 
examples are mad, vorbis, osssink and filesrc.

> 2) The plugins are too granular for my needs.  What I want is: 
> 	"load this mono synth and convert it to stereo"
> 	"connect it to this FX Bus, which has N effects, all stereo"
> 	"connect all the FX Busses to the master bus"
> 	"send the master output to {OSS, ALSA, file, whatever}"
> I'd need to build a way to group many GST plugs into atomic units

You can easily do that.  For your own app, you write simple structs 
(objects) with methods to create and connect them.  It's pretty easy to go 
up one level of abstraction with GStreamer as the basis - gnonlin, Wim's 
non-linear editor library does this as well, by further subclassing the 
basic elements he needs.

> 3) I'm concerned about performance - some of the tracks I've seen in windows
> used 50 or more simultaneous voices at times, and it was REALLY hard on the
> CPU.  GStreamer seems very higly normalized, which adds a lot of overhead -
> is it a real problem I should worry about?

We should do some hard numbers to convince people.  Suffice it to say that 
the core is really fast and adds little overweight (provided you don't 
make the buffer size too small, of course).  Anyone have an idea on how we 
can start getting numbers on this to convince non-believers ? 

> 4) The bleeding edge tools needed to build GStreamer made it VERY hard for
> me to get installed and running - and I know what I am doing.  An average
> user would NEVER be able.

An average user should stick to
a) packages for his distribution (we provide good redhat and debian 
packages)
b) tarball releases.

Also, all of the tools needed for building from CVS were present in red 
hat 7.3, for example.  We used to be a lot more bleeding edge, requiring 
patched autotools and so on, but these days, all you need is a halfly 
recent set of autoconf/automake/libtool, and pretty much any version of 
libxml2, glib2, and popt.

> 5) The GStreamer goals really seem to be very focused on playing media
> (especially video) and doing magic.

Yes, without ignoring the simple things.  I have one simple audio app that 
archives audio by hour to mp3 and ogg which has been running for almost a 
year now at work, and another to detect high-pitched frequencies in a 
broadcast signal that's been working for a month.

> 6) Has anyone started an app like this?

Not that I know of.

> I'm still torn between finishing my own, much simpler, plugin API and using
> GST.  I need something to sway me :)

We'd love to have you on-board and provide us with feedback, as well as be 
able to help you.  Your best bet is to come and discuss it on irc 
(#gstreamer on irc.openprojects.net).

We'll get a better view of what you want to do and what we can help with.

Thomas

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
Take my hands between your knees
Once inside
I'll only take the things that shine
You always said those things were mine
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/