From: Colin W. <wa...@re...> - 2004-11-29 02:39:46
|
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. |