[gst-devel] sample caching

Colin Walters walters at redhat.com
Sun Nov 28 18:40:05 CET 2004


On Thu, 2004-11-25 at 10:43 +0100, Ronald S. Bultje wrote:

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

That's not really the same thing though; in my suggestion,
GstAudioFramework would act as a factory.  The elements it creates do
not necessarily inherit from a common superclass.  And probably, you'd
only have one toplevel GConf key for the soundsystem, so things would
look like this:

GstAudioFramework *framework = gst_gconf_get_default_soundsystem ();
GstElement *sink = gst_audio_framework_get_sink (framework);
GstElement *cacher = gst_audio_framework_get_sample_cache (framework);

The framework could share a single fd between the sink, sample cache,
etc., with locking as Benjamin noted.

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

That's ok by me if we go that route, I was just trying to address
Benjamin's concerns.






More information about the gstreamer-devel mailing list