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

[Tim Hockin]

> > 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 inclined to believe that.  I think a lot of the complexity comes from
the lower levels.  GLib and friends are something that just need time to
adjust to.

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

Ok, I will.

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

This is very true.  There are some things about GObject I find really
awkward - the seperation of BaseClassInit, ClassInit, and Init methods, for
one.  Or the fact that if I don't provide one of the above, my superclass
doesn't get called instead.  I'm also very confused by what objects can be
cast to what - what goes into my FooClass struct?  Can I cast my Foo to a
FooClass?  How can I access my super-class' ClassInit function?

Fortunately Gst seems to not need to much magic, but I like to know...

> Also, not all plug-ins are of equal quality.  Good plug-ins to look at for 
> examples are mad, vorbis, osssink and filesrc.

Point noted.

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

Yeah, I'm realizing that.  Some of the things I'm going to want, real soon,
and I'm not sure how to get:

a Source that reads audio files into memory, does some static processing on
them (for example normalize to 0dB, phase invert, bit crush) and then sets
start/end markers.  Some incoming signal then tells it to play the sample,
and it plays only the stuff between start/end.  Further, it will eventually
need to pitch shift the sample and track some level of polyphony (prefer it
to be unlimited).

I'm not sure whether I should be writing a sampler plugin which has all
these parameters and knobs, or whether I should be hacking an existing one,
or whether I should be conniving some way to chain smaller elements
together...

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


I'm not sure that will help - the problem is 'what is a typical workload?'
I;d want to see 50 voices with 25 64-bit software synths running
simultaneously.  This setup would chew up my 933 MHz system, and barely
survives on my 1266 P-III.

Secondly, my app almost HAS to have small buffers - one of the goals is
realtime playability, which means were talking buffers that are in the
100-200 samples range, and latency in the 2-5 ms range.  Of course, I don;t
expect 50 voices to run at that granularity, but I expect 10 or 20.

> 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 

RH7.3 did not have a new enough autoconf - I had to grab it from GNU and
compile it.  I admit that the average user doesn't need these things, but it
was very frustrating for me to spend almost 2 days getting tools and
dependencies together, upgrading, building, installing.  It finally builds
(except gst-player and docs for gst-editor) for 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).

I'd love to be on board - better to have a team.  I appreciate the helpful
letter.  I'm going to play some more today, and maybe see you all on irc.

Tim