[gst-devel] a good GStreamer design issue question

[Andy Wingo]

This is a funny debate that sprang out of nothing ;)

On Tue, 23 Sep 2003, in7y118 at public.uni-hamburg.de wrote:

> Second, querying the time it will take to output the data is not
> possible.

What is gst_pad_query()ing for GST_QUERY_LATENCY supposed to do then? Or
any other kind of query for that matter.

> IMO it shouldn't be possible - at least not for an element.

Of course, it would be the application that would query and compensate
for the latency. It's the application that has to update the gui, the
job belongs there.

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

This would probably work, although it does involve buffering the audio
signal (not possible in a single-buffered alsasrc ! level ! alsasink,
for example). Also it does not take into account the latency of the
hardware, which can be considerable.

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

There is an asyncronous wait as well, for the record -- irrelevant to
this topic, and only AudioClock implements it now, but just so you know
it's there (if you missed it when it was added)...

regards,

wingo.