[gst-devel] a good GStreamer design issue question

[in7y118 at public.uni-hamburg.de]

Quoting Andy Wingo <wingo at pobox.com>:

> What is gst_pad_query()ing for GST_QUERY_LATENCY supposed to do then? Or
> any other kind of query for that matter.
> 
It is supposed to provide you (or better: the application, I'm not sure if 
elements should use queries - I think queries should just die anyway, they're 
horribly complicated) with an estimate. So I guess your right, with (lots of?) 
querying you could get a vumeter display done correctly - and probably your CPU 
down, too.

> 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 latency of the hardware is to be taken care of by the clock and the clocks 
do that right now, so that should not be a problem.

> 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)...
> 
And the schedulers do take this into account? And are elements changed to use 
that? I still want my threadless video playback! :)


Dude, I really start thinking that if anyone ever starts doing a big serious 
pro-audio application with GStreamer, we're really gonna get bitten hard by 
some stuff. ;/

Benjamin