[gst-devel] I want to do an audio app
thockin at hockin.org
Sun Sep 22 11:31:03 CEST 2002
> > 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
> > 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.
> 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
> > 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.
More information about the gstreamer-devel