[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