[gst-devel] a good GStreamer design issue question

[Thomas Vander Stichele]

Hi all,

while working on fixing up level so I can actually display audio levels
for an application I'm working on, I came to a halt when trying to
figure out the proper way to do something.  It might be an important
general issue to consider, so help a brother out :)

Here's the thing.  There's a level plugin right now that prints out the
RMS level of each buffer passing through.  That's obviously not very
useful, so I started fixing it up, making it faster, and fixing general
stupidities.

After some time, I had an element that signaled proper values for
display by a VU meter.  The problem was, since it was analyzing audio
before it went to the sink, the VU meter displaying the audio level was
preceding the actual output. It would be nice to find some way to fix
this.

So, here are some thoughts:

a) one possible way to solve this would be some trickery in having the
level plugin emit the signal only at the right moment by telling the
clock to wait on the timestamp of the buffer; don't know if that would
work, though
b) another way would be some way to query the downstream delta; ie, try
to figure out how much time it will take before playback
c) a third way, and this is my preferred way, is to somehow get the
calculation logic also in the sinks directly.  Ie, any of the audio
sinks would be capable of emitting level signals and doing the
calculation.

Now, to achieve c), there are a few things I wonder about.  The easiest
way to do this would be to create some sort of GstAudioElement
superclass, which had all the provisions for doing this (ie, private
data, calculation routines, and signaling stuff).
Then we could have output sources and sinks, and filters, descend from
this.

That might interfere though with other ideas of subclassing (ie, I
remember some people wanting to subclass oss sinks from a clock
providing element superclass), so maybe there are better ways of doing
this ?

I have also thought about putting all of the calculation stuff in the
audio library, which would work; the drawback is that each element still
has to implement getter/setters and signaling and so on.

Maybe something like this is also possible with interfaces ? Or should
it only be connected to the pads ?

I'd appreciate feedback; it would be sweet if we could fix up sound
recorder and other apps to have a level indicator.  I'm willing to code
on this right now.

Thomas


Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
They say if you love somebody
you have got to set them free
but I would rather be locked to you
than living in this pain and misery
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/