[gst-devel] a good GStreamer design issue question

[in7y118 at public.uni-hamburg.de]

I'll just write this as an answer to everybody at once, as I think I'd comment 
one line to everything. I'll come to my opinion on how to do this later.

First, this is not really the place where you want to add an interface. An 
interface is just an API (= application programmer interface) for 
application/element interaction. It's not for solving problems, but to 
formalize the interface to the solution.

Second, querying the time it will take to output the data is not possible. IMO 
it shouldn't be possible - at least not for an element. An element is just one 
position inside a stream, it has no knowledge about what happens upstream or 
downstream. (I imagine it like this: An elemeent is like some guy standing at a 
river. He can look upriver and downriver and see what water comes and where the 
water goes and can even do stuff to the water. But he will never know what 
happens after the next turn in the river, let alone at the end of the river.) I 
try to stick to this as much as possible, because only then can you connect all 
elements to each other problemlessly.
The only thing that is possible is waiting for some point in time to happen via 
listening to the clock.

> 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
>
This is not really what a filter could do, because that might cause problems 
downstream. GStreamer only allows one source and one sink per thread to block 
(which is why you need threads for proper A/V sync.)

> 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
>
I wrote above why I think this is not a very good idea.

> 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.
> 
No. An audio sink is an audio sink and only an audio sink. And an audio sink 
outputs audio to the sound output. If that requires computing a level, then it 
may very well do that. If it doesn't require that, then it's the wrong element 
for the job.
Don't bloat the elements. Let every element only do one well defined job.


Ronald's idea sounds quite nice to me already, though my first idea was a bit 
different (*fetches ascii art stick*):
           ---> { queue --> osssink }
          /
--> level
          \
           ---> { queue --> fakesink }
level would have an output in a new level-based mimetype - people may even want 
to use that later on for a normalization element or feed its output to gst-sci 
or whatever.
This makes sense because the level information is a new data stream really.

Some more on the implementation: You can set a property on fakesink to TRUE and 
then fakesink will synchronize to a clock. After that, you connect a handler to 
fakesink's handoff signal that updates the vumeter (or passes it the buffer 
data to update frame-based for added CPU usage).

The thing that might sound a little complex now is the fact that we add a lot 
of elements to the pipeline. This should not be a problem though. I expect to 
see pipelines with 1000 elements in the future (Cubase for GStreamer with 
included gst-based synthesizers), so 2 more elements shouldn't be a big thing.

The only problem is that every element waiting on the clock needs its own 
thread. This is a bug I'd mark 1.0 or 1.2 :)

Benjamin