[gst-devel] volume plugin with dparams

[Andy Wingo]

greetings karsten,

On Wed, 14 Nov 2001, Karsten N . Strand wrote:

> I'm currently looking into gstreamer as the platform for my new digital
> audio mixing system project, and have a few questions. 

join the club ;)

>The plans for the
> mixer is to build a external control board with sliders, aux buttons, and
> two "turntables" (for scratching, searching and looking cool), using a
> board with a bunch of adc's and a philips P89C51RC+ controller chip. The
> control board will have a serial interface. This step is pretty
> straightforward, with some kindly given soldering help from my father.

sounds quite interesting.

> The next step is to hook all these controls up to actual mixing software,
> and this is were I thought maybe gstreamer could be The choice. I have been
> following the project for a while, and I really think it's the future for
> streaming media in linux (the gtk/gnome world anyway, it seems like the
> qt/kde people have somewhat settled for arts). Well, anyway, that's my
> story.. Here's the questions:
> 
> Is anyone working on adding dparams to volume?

no, although it's my plan for the future. i wrote that plugin (at least
the one in plugins/filters/volume), so if you get to it before i do,
send me a patch and i'll put it in there.

> Are the latency numbers good?

anyone? as i understand it, gstreamer's architecture does not have any
fundamental problems operating in a low latency environment. that said,
there might still be some issues to hammer out. the alsa plugin still
needs some tweaks (although it is up-to-date wrt alsa cvs) but i can get
down to 64 frames/period (a period in alsa is like a fragment in oss),
although if i switch processes i get xruns. this should be solved by
using the appropriate kernel patch and/or SCHED_FIFO.

> Any work on some kind of sequencer to record stream changes and dparam
> values?

i'm not sure. this would be one level higher than the gstreamer level,
although it would have to interact with gst. 

> Any plans for a terminatorX-like* element for gstreamer? terminatorX (
> http://terminatorx.cx ) is a kickass virtual turntable app for linux, but
> you probably knew that anyway :)

I've thought a little about this. The turntable analogy has a couple of
'models':

1) you have the situation where the turntable is going, you're
just speeding it up and slowing it down. you can do that now with speed
or audioscale (they'll use the same base library soon, the one in
libs/resample). 

2) where the turntable's stopped and you're 'scratching'. you can either
buffer the output and 'scratch' within the buffer (this is what tX does,
it's pretty nasty when you think about it: why should I have to
decompress an entire mp3 to scratch?). you would implement this element
in such a fashion that you could scratch streaming media. the other
option would involve lots of seek events. you can't play backwards in
gstreamer at the moment, so this would be hackish. i haven't figured out
a good way to play backwards though. you'd probably first have to make a
flag on source elements as to whether they are seekable or not. if they
are, you can probably scratch, although it might require a buffer
(queue) on high-latency sources. you probably don't want to scratch on
that type of source anyway. these are just ideas.

3) like 'scratching', but controlling dparams. once ladspa's dparam-ized
(hi steveb :) this could change, for instance, the delay of a flanger,
taking the place of the lfo in a flanger. something like that.

lots of possibilities :)

> I would very much like to help with any of these issues, as they're all
> vital to my application, but I'm no wizard, so it might take some time to
> me to understand gstreamer's architecture and api completely. I've never
> had any experience with GObjects (just basic gtk+) before, and I think the
> official docs is pretty sparse at this moment, so I would be grateful for
> pointers to good alternative documentation.

gobjects are just like gtkobjects, with a few exceptions, so the ggad
(linked to from gstreamer.net/wiki/?ReferenceLibrary) is still quite
useful. the app developer's guide is nice, and the wiki has some more
stuff. so read all that, then we'll see you on irc :)

or, just dive into the source. try running this (if you have the mad mp3
decoder installed):

$ gstreamer-launch --gst-mask=-1 filesrc location=foo.mp3 ! mad ! \
> osssink 2>&1 | less -R

that's a lot of info, it helps you see when things get done.

> If anything useful come out of the mixer project, I will (oh'course)
> release the code and schematics under lgpl, gpl. And then, maybe someone
> else will want to be a part of the project too, and we will take over the
> evil music industry together, and ride happy into the sunset :)

saddle up! :-)

cheers, to the future,

wingo.