Re: [gst-devel] sample caching

[Iain * <iai...@gm...>]

S'pose this is where I come in...

On Tue, 23 Nov 2004 13:58:00 -0800, Leif Johnson <le...@am...> wrote:
> Colin Walters wrote:
> > One difficulty here is that apps will just get the sink from GConf,
> > which could be a bin containing e.g. audioconvert and audioscale too.
> > So we'd need to make GstBin implement GstSampleCacheInterface too, which
> > would suck.  Is there a better way?
> 
> Why not use a dedicated element that caches samples ? Seems like any app
> (e.g. sample synth, sound server, video editor, etc.) that knows it's
> dealing with cached media will be just as easy (or difficult) to write
> using a cache element as it would be using a sink that implements a
> cache interface.

You can't use a dedicated element to cache the samples, because the
samples are not cached in the pipeline.

consider

filesrc ! spider ! polypsink

polypsink is connected to the polypaudio daemon.
It is this daemon which does the caching, not the polypsink. The
caching of the sample is not to reduce the time spent in the spider,
it is to reduce the time going from the polypsink->polyp daemon. So a
GstCacheElement would not help there.

As to Colin's issue. We could create a function
"gst_bin_get_real_sink"[1] (I've implemented a similar function for
part of Marlin) which returns the real sink given a GstBin.

In my ding caching stuff that I've been quietly working on (slowly,
it's essay season), would use such a function, but the user of the
ding caching would just call gnome_sound_play [1] and everything is
taken care of for him.

iain

[1] All function names are subject to "Iain, your ability to name
functions sucks!"