[gst-devel] Buffer-frames considered useless in 0.9

[Andy Wingo]

Greetings,

I think the buffer-frames property of float caps is useless in GStreamer
0.9. I will remove mentions of it from the docs soon, unless I hear any
objections (unlikely).

The reason it was there was to allow for efficient processing of
complicated audio processing pipelines, given the iteration-based
scheduling in 0.8. If an element was written in loop mode, it was much
easier to program when a pull was guaranteed to produce N samples rather
than having to deal with different numbers of samples on every sink pad.
Also it prevented buffering when pushing two source pads to two sink
pads between two elements.

It was never necessary that the underlying DSP algorithms, like the ones
in LADSPA plugins, know their processing block size beforehand. So for
the single-in, single-out, chain-scheduled case, buffer-frames was just
a complication of capsnego.

In 0.9 we can get rid of it because pull_range allows us to specify the
number of samples the plugin should produce, if a flow is scheduled in
pull mode. Push mode is a bit trickier; since there might be multiple
sources, and push mode starts threads at each terminal source, you have
to be prepared to get data from any thread. Fortunately Wim is clever
and wrote GstCollectPads (gst/base/gstcollectpads.[ch]), an abstraction
for use with multiple-sinkpad elements, which will use threads only if
necessary.

I'm working on a signal processing base class that will present a
higher-level interface than buffers and pads; but the end of the story
is that I think it's possible to do complicated DSP pipelines
efficiently without the use of a buffer-frames property. So be advised
that it is going away.

(Pleasantly, this means you should be able to do "decodebin !
audioconvert ! random-ladspa-plugin ! audioconvert ! alsasink", without
the need for buffer-frames or getting strange errors at capsnego time.)

Comments or questions?

Regards,
-- 
Andy Wingo
http://wingolog.org/