[gst-devel] Problem choosing the right scheduling mode

[Dominique Würtz]

Hi,

I'm currently trying to implement an element which generates peak 
information (min/max value pairs) from audio data to be used for 
waveform drawing. Reading through the PWG and experimenting with the 
various scheduling modes, I found each mode to be unsuitable for 
different reasons I want to explain below. The main issue with my 
element is the possibly significant input/ouput buffer size ratio:
* For very low zoom factors, you take many audio samples and ouput a 
relatively small number of peak values.
* OTOH, a high zoo factor means taking only a bunch of samples and 
render them into a large chunk of peaks (say 1 sample could be displayed 
50 pixels wide)

So here is what I found when evaluating the scheduling modes:

1. chain-based: incoming (audio data) is pushed on the sink pad. This 
works ok of low zoom factors, because I can collect the incoming buffers 
(for ex. using a GstAdapter) push out the generated data once I have a 
sufficient amount of samples at the input. However, for high zoom 
factors, it won't work (well). In this case, I have to generate a large  
number of peak data for a relatively low number of input samples. This 
is bad, firstly because I think buffer sizes of maybe 100kbytes are 
simply bad practice and secondly large buffers mean possible overhead, 
because the downstream element could only need part of the data, 
discarding the major part of the expensively calculated data.

2. GstTask-based: this would basically work well. Main problem here is 
that it requires the upstream elements to provide random access, which 
unfortunately not the case for elements like wavparse and actually not 
required for my task.

So to sum things up, at this point I see no way to get things done with 
current GStreamer but I'd be glad if someone come up with an idea.

Just as a suggestion, the optimal scheduling mode for this kind of 
element would be an additional pull-based chain mode: a chain callback 
is attached to a _source_ pad where data is pulled (no random access!) 
from sink pads. The new gst_pad_pull() function could then also be used 
as an alternative to get_range() in GstTask-based elements, making it 
possible to connect chain-based elements upstream.

I hope I explained myself properly and appreciate any comments!

Cheers,

Dominique