[gst-devel] sample caching

[Ronald S. Bultje]

On Thu, 2004-11-25 at 06:02, Colin Walters wrote:
[..]
> > What I would prefer would be an abstraction that makes audio frameworks a
> > first class struct in GStreamer.
> > Kinda like this:
> > struct GstAudioFramework {
> >   GType inputelement; /* GST_TYPE_ALSA_SRC */
> >   GType outputelement; /* GST_TYPE_ALSA_SINK */
> >   GType volumechanger; /* GST_TYPE_ALSA_MIXER */
> >   ...
> > };
> >
> > We could then add _one_ interface to each element that requests the audio
> > framework. After that we could nicely query the framework about supported
> > capabilities and also add capabilities later on without the need to
> > fiddle with the elements and risking to break playback with every change.
> 
> Why not do it the other way around: Make GstAudioFramework a first-class
> object (plugin) and have methods for retrieving the source, sink, volume
> control, and sample caching elements.  This is conceptually cleaner I
> think because that way they can easily share data such as a connection
> to the sound server, or an open fd on a sound device.

That's what we currently do. There's a toplevel GstAlsaElement (or
GstOssElement, ...) class that derives from GstElement. It contains the
file descriptor (or alsa handle). For OssElement, the mixing
functionality is built-into this class (could be separated, that'd be
somehwat more perfectly clean). For ALSA, there's a child class
GstAlsaMixer that has this. Then there's GstAlsaSink/Source that derive
from the mixer and OssSource/Sink that derive from the OssElement. I
considered this cleaner than Benjamin's proposal, because it allows me
to use the mixer interface on sources (i.e. I open a osssrc and can then
adjust volumes on line-in using that very same object). Benjamin seems
to disagree. I kind-of see his point with the sinks. The thing is that
other players do the same thing. Helixplayer, for example, uses the
mixer of the audio output for volume control (yes, it uses hardware
volume). Totem could do that too, by only a minor change.

As for the caching interface, only backends explicitely supporting this
would implement the interface, which is currently only esd (if anyone
feels like implementing that) and polypaudiosink. Alsasink/osssink won't
get any new code because they don't implement sample caching. I don't
really see the problem here...

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>